[Seaside] YUI

[C. David Shaffer]

Sebastian Sastre wrote:


> So maybe it's time to evaluate the option. I think before convincing myself
> of that having sense I would: 
>
> 1. one should quantify that impedance
>   
a) All UI-related state of the components is on the client.  Smalltalk 
side only informed of desired events.  This really isn't much different 
than the usual HTML input components.  It is also very similar to 
"native widget" GUI interfaces found in some Smalltalks.  Much of the 
debate of native versus emulated widgets applies here.

b) Events provided by the client can be handled by JS in the client or 
by Smalltalk (via Ajax) in Smalltalk.  Just as with Scriptaculous.

c) There are very few full page redraws so renderContentOn: needs to be 
well factored so that parts of a component can be re-drawn as needed.

> 2. see if one finds a mapping design that is useful for the long run
>   
...I can't address this.  Maybe once this full app is deployed.
> 3. see if the the life of ExtJS will be long enough to make this worth
>   
One never knows about these things.  The have a solid product, large 
community and great support.
> 4. evaluate ExtJS community support
>   
above
> 5. see if the design will pollute or not the seaside-smalltalk way to do
> things (easiness to virtualize conceptual models)
>   
If you aren't careful your Smalltalk code looks like "Javascript in 
Smalltalk".  I tried the approach Lukas provided with Scriptaculous 
(Smalltalk objects represent Javascript statements, can be decorated 
etc) but it was too verbose.  I've looked at ST2JS and finally think I 
understand it but I think it might be taking things a bit too far.  
Right now I'm looking for something in the middle.  I want to write 
Smalltalk-looking code which manipulates Javascript objects.  I want the 
API of these Javascript objects to be explicit in Smalltalk whenever 
possible with the option of having "generic objects" when I'm not sure 
of the return type of something.  I'd like to be able to perform 
Smalltalk computations that aren't translated to Javascript as well as 
pass Smalltalk blocks to be used as callbacks.  This is a challenge.


> Why we can't have our own (community) hierarchy of gorgeous widgets on top
> of smalltalk-seaside-prototype-scriptaculous?
>
>   
This just hasn't happened.  The Seaside "components" that you can find 
simply don't cover as broad a spectrum as something like ExtJS.  
Producing this kind of tool set in Smalltalk is outside my area of 
expertise (and interest).  Having said that I'd much rather work on an 
app that didn't require something like ExtJS because there's always that 
feeling that you can't deal with problems if they occur.  Fortunately 
armed with Firebug and a rough knowledge of Javascript I haven't hit any 
snags.

David