[Seaside] YUI

Sebastian Sastre ssastre at seaswork.com
Wed Oct 31 19:35:00 UTC 2007


> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre 
> de C. David Shaffer
> Enviado el: Miércoles, 31 de Octubre de 2007 14:35
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] YUI
> 
> 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.
> 

Yes I also see this. The question here is what in the html/javascript domain
would be more convenient for us?
Before trying to answer that I think in two things: 1) how many changes the
OS native widgets has experimented, so it's programatic interfaces and 2)
how many widgets you found in the web domain (I see a lot more). Seeing
those two considerations now I'm wondering how to ponder how much clever
could be an early compromise with a "native" widget implementation for the
web domain. Experience indicates that Smalltalk solutions use to perdure.

> 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.
> 

I don't saw requests while using it so I think they are also using comet or
something like that.

> 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.
> 

Naturally that is needed for any option. For instance I already done that
for some presenters (seaside components) in the MVP hierarchy I made for my
widgets.

> > 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".  

Totally agree. That's why I factorized things to the point of being able to
use a Smaltalkish well proven framework like MVP. When I need an updater in
a presenter I call it and only customize it's callback so verbosity is not
my problem anymore. Hierarchies of similar "widgets" form families of
presenters with factorable scripts and so on.

>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.
> 
Indeed it is. The problem is that you don’t have the javascript part enough
prepared to perform a smalltalk experience. Think in our debugger. Believe
me I've tried to give a little step in that direction. Using javascript
objects ala Smalltalk is too much for the JS VM that todays barely performs
reasonable garbages collections. A JS Dictionary performs miserably todays.
That’s why it's used so "hackishly". Improvments in JS VM will help us all
but that it's not in our hands.

> 
> > 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
> 
Of course not that's why I instigated us with my question :)

I'm still conviced (since 2003 or somethig like that) that the MVP pattern
also applies to the web domain taking advantage of seaside using prototype
and scriptaculous as if they where the low level API that the OS gives you
in the metaphore: web browsers are our new OS.

We all love out of the box solutions but in smalltalk we have to make it
happen !
I like to see this happening in Smalltalk - Seaside,

	cheers,

Sebastian



More information about the seaside mailing list