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

[Michael Lucas-Smith]

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:
> 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 <itsme213 at hotmail.com <mailto:itsme213 at hotmail.com>>:
>
>     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
>     seaside at lists.squeakfoundation.org
>     <mailto:seaside at lists.squeakfoundation.org>
>     http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>