Mootools with Seaside (Hernan? Boris? Michael Lucas-Smith? Others?)

Anyone here working on (or know the status of) a mootols-with-seaside?

(Google seemed to think that Hernan Morales had done something; Boris Popov
was about to do something; and Michael Lucas-Smith was wrapping up
something - all with Mootools + Seaside).

Thanks - Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I had started down that path, but got sidetracked with much larger
projects for the moment. I suspect Michael's work on VisualWorks version
is where I would start looking.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Same situation as Boris here, wrapped up in exhausting work. I think it worth a second try this week-end.
One thing, note that you cannot use currently both MooTools and Prototype-Scriptaculous at the same time, at least not without some hacks.
From my porting experience I can tell you that to keep the MooTools API on the same flavor as the Scriptaculous API is a hard work because of they are used in different ways, as usual, the devil is in the details.

Hernán



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I second that sentiment. Mootools is not something you use like
Scriptaculous. Mootools is there to help you build Javascript easier.
It's not inherently as wrappable as Scriptaculous.

In my implementation I ended up wrapping up Request, Request.HTML and
the Fx hierarchy. But more importantly, I provided a dynamic compiler
system to allow developers to make subclasses of MooBrush (subclass of
WATagBrush) which combined Smalltalk, Javascript and CSS together to
build up "widgets".

The Javascript is installed in to a Mootools Class, giving a very tight
analog between the Smalltalk server side code and the Javascript client
side code.

The point I'd like to make here is that Mootools helps me day to day
building client side javascript. Scriptaculous is far more pre-packaged
than that. If you were to do a comparison, it's Mootools and Prototype.
There's no Scriptaculous equivalent built on Mootools - nor is it likely
there ever will be, that's simply not what they're trying to do.

I have no problem if people are interested in porting my
Seaside-Mootools implementation from VW to Squeak. I think it would be
fairly straight-forward. Seaside-Javascript is basically the javascript
side of Seaside-Scriptaculous and I was under the impression this was
being separated for Seaside 2.9 anyway. DynamicCompiler may be the only
tricky bit - it switches between Javascript, CSS and Smalltalk
scanning/parsing dynamically. I have tests for it though.

Although, if people want Seaside to really get the most out of a close
marriage between javascript and smalltalk, there are other significant
design changes that could be implemented to help aid that.
a) One thing my colleagues and I discovered when we built our comet
driven web framework a few years ago was that you tend to want only one
tree to represent your UI state on the server, not two - instead of
having WAComponent and WABrush separated, we combined the two so that
each widget was an element which was also represented on the client side
as a DOM node.
b) Each element we generated from the server we may want to change and
often did dynamically, so we would give each element a generate id
instead of piecemeal choosing to do it
c) We made the entire UI on the server side a DOM tree and each "widget"
was a subclass of Element. It would modify itself (or other nodes it
knew about) and the act of doing so would create a ChangeSet to the DOM
tree which is sent as the response to a request from the web browser.
The web browser would execute the ChangeSet to modify its own DOM tree
to stay in sync with the server.
d) We used comets so that a server side process could initiate sending a
ChangeSet back to the client even when the client hadn't initiated an
action. In the end, this was used less than we thought we'd need it, but
it was still cool - i'd say it's a nice add-on to a framework.
e) Because all interations were done with (Mootools) Request calls the
URL of the page would never update, thus avoiding the Back button
problem that continuations solves. Instead, we used a javascript trick
that allows you to change the URL on the page and add it to the pages
history dynamically - that meant that at certain points in server code
execution, the server could say to the client "now you are on a page
that has a solid URL that I can return to". This facilitated building
all entry points and REST based APIs
f) Because there was only ever one page on the server to represent a
single user, there was rarely any memory concerns. There was also no
passes to process actions and callbacks, those were registered in to a
weak dictionary so that if an element was destroyed, so was the callback.

I'm sure there were more lessons learned but I've probably forgotten
them right now :) ... there's nothing in Seaside that inherently stops
anyone doing something like the above, but we wrote our own framework
because Seaside didn't work in VisualAge :) ... and also we discovered
that we needed a great deal less code by the time we were finished.
Seaside has evolved a lot since back then and it is a lot faster and a
lot more factored, so I'm not sure the assumptions we made back then
hold true any more.

Anyway.. that's a bit of a ramble about how we used Mootools previously
and how I'm using Mootools now.

Cheers,
Michael


Hernán Morales wrote:
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Really interesting...

A bit off topic,do you know dojotoolkit,
http://dojotoolkit.org/projects/core. I first thought it was based on
Mootools, but it doesn't seem to be.

I've seen an implementation start of the dojo charts on squeaksource (seachart).

Is dojo interesting, I mean compatible with seaside ? not too much bloated ?

Cheers,

Cédrick

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

cdrick wrote: We actually migrated from DojoToolkit to Mootools. We started off with
dojo because it seemed ideal for our needs - here were a bunch of
widgets that we could wrap up and use from the server side. However, we
quickly discovered that they don't really put any stock in object
models, so the widgets were generally one-shot deals. Once you'd made it
and put it up on the screen, that was how it was going to be. Now, we
had a dynamic server model that allowed us to change anything on the
client we wanted anytime we wanted.. the two approaches didn't mesh.

After using Dojo for a while, we got more confident, learnt Mootools and
realized we could make the widgets ourselves.

Also, I would definitely classify Dojo in the 'bloated' category :)

Cheers,
Michael
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I know there is a trend to make conviviality possible between libraries, but jQuery is already able to live toghether whit Prototype and Scriptaculous peacefully. And jQuery seems to have a very object(ish) style.
So I ask what features MooTools have which Prototype/Scriptaculous and/or jQuery don’t?

        cheers,
 
Sebastian Sastre
________________________________

        De: [hidden email] [mailto:[hidden email]] En nombre de Hernán Morales
        Enviado el: Miércoles, 13 de Febrero de 2008 02:04
        Para: Seaside - general discussion
        Asunto: Re: [Seaside] Mootools with Seaside (Hernan? Boris? MichaelLucas-Smith? Others?)
       
       
        Same situation as Boris here, wrapped up in exhausting work. I think it worth a second try this week-end.
        One thing, note that you cannot use currently both MooTools and Prototype-Scriptaculous at the same time, at least not without some hacks.
        From my porting experience I can tell you that to keep the MooTools API on the same flavor as the Scriptaculous API is a hard work because of they are used in different ways, as usual, the devil is in the details.
       
        Hernán
       
       
        2008/2/12, itsme213 <[hidden email]>:

                Anyone here working on (or know the status of) a mootols-with-seaside?
               
                (Google seemed to think that Hernan Morales had done something; Boris Popov
                was about to do something; and Michael Lucas-Smith was wrapping up
                something - all with Mootools + Seaside).
               
                Thanks - Sophie
               
               
               
                _______________________________________________
                seaside mailing list
                [hidden email]
                http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
               



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

"Michael Lucas-Smith" <[hidden email]> wrote

> Anyway.. that's a bit of a ramble about how we used Mootools previously
> and how I'm using Mootools now.

Very helpful ramblings, please keep on rambling !

Thanks - Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

"Michael Lucas-Smith" <[hidden email]> wrote

> There's no Scriptaculous equivalent built on Mootools - nor is it likely
> there ever will be, that's simply not what they're trying to do.

Perhaps widgets like MochaUI or MooTabs (if well designed) might be?

> a) One thing my colleagues and I discovered when we built our comet driven
> web framework

Is framework that still around, and by any chance accessible?

Several points in your description sound very interesting (to me). It would
be great if Lukas or Avi have some insights to share on these different
approaches.

> e) Because all interations were done with (Mootools) Request calls the URL
> of the page would never update, thus avoiding the Back button problem that
> continuations solves. Instead, we used a javascript trick that allows you
> to change the URL on the page and add it to the pages history
> dynamically - that meant that at certain points in server code execution,
> the server could say to the client "now you are on a page that has a solid
> URL that I can return to". This facilitated building all entry points and
> REST based APIs

Was the intent to totally replace back-button usage with this? Or to be able
to combine both mechanisms? If the latter, would you not need something more
than your (f)?

> f) Because there was only ever one page on the server to represent a

> There was also no passes to process actions and callbacks, those were
> registered in to a weak dictionary so that if an element was destroyed, so
> was the callback.

I wonder if something like the latter (removing callbacks when their
components are removed) could be done with Seaside+SU today, and if it might
solve some cases of "missing-component".

Thanks!

Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside