[Seaside] Pondering if Dojo javascript toolkit is moreconvenientthan Scriptaculous for Seaside solutions

Sebastian Sastre ssastre at seaswork.com
Thu Apr 26 18:55:14 UTC 2007


> I don't see any harm in using whatever JS toolkit that would 
> make your life easier. Here, for instance, we use both 
> Scriptaculous/Prototype and YUI extensively, even mixed together,
> 
Right. And I wrote that because I've found Dojo could lead us to a far more
complete UI solution than Scriptaculous and even Yahoo UI (I don't know
about Prototype). Is not that they aren't good. I use some Scriptaculous
myself as you say. But one (and customers and consumers) allways want more
right? So I'm talking about the near future of Seaside based online systems.

Perhaps I'm worried more because I have no idea of what javascript develop
could mean, and that I don't want to know what that mean, but I do like the
results I've see. I'm aware that those results are valuable javascript that
could bring us cosmetic, usability and ajaxian (events) but no more than
that. For the rest is Seaside and Smalltalk itself.

So I'm questioning here if the community could use some coordinated effort
on mapping Dojo to go togheter further adding Dojo features to Seaside
sarting today in contrast with fragmentated efforts that could (or could
not) be reached and perhaps adopted tomorrow.

So.. Did you take a look into Dojo widgets?

Regards,

Sebastian



> (html anchor)
>  class: 'settings';
>  onClick: (html
>              yuipanel: editor
>              config: [:v | v close: true]);
>  with: 'Settings'
> 
> where,
> 
> yuipanel: component config: block
> (self updater)
>  evalScripts: true;
>  id: 'yuipaneltarget';
>  onFailure: ((SUStream new)
>                nextPutAll: 'displayGenericError();';
>                yourself);
>  callback: [:render | 
>     | dialog |
>     dialog := (Seaside.YUIPanel new)
>                 immediate: true;
>                 delegate: component;
>                 yourself.
>     block value: dialog.
>     dialog renderContentOn: render];
>  yourself
> 
> So it's really up to you to decide what tool is right for the job.
> 
> -Boris
> 
> -- 
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
> http://tinyurl.com/r7uw4
> 
> boris at deepcovelabs.com
> 
> 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.
> 
> > -----Original Message-----
> > From: seaside-bounces at lists.squeakfoundation.org [mailto:seaside- 
> > bounces at lists.squeakfoundation.org] On Behalf Of Sebastian Sastre
> > Sent: Thursday, April 26, 2007 10:28 AM
> > To: 'Seaside - general discussion'
> > Subject: [Seaside] Pondering if Dojo javascript toolkit is more 
> > convenientthan Scriptaculous for Seaside solutions
> > 
> > Hi there,
> > 
> >     I like to share some ideas about the value equation 
> (scoring) of 
> > Seaside systems (solutions) and to purpouse to evaluate 
> somethig that
> I
> > suspect that could add value this equation so, if this 
> suspiction is 
> > finally right, it will add value for all the comunity, so 
> we all won.
> > 
> >     Imagine you have a scoring equation wich defines the 
> value of your 
> > seasside solution. This equation have the general form of:
> X1+X2+..+Xn
> > 
> >     Each term is a function of value (scoring) of different domains:
> for
> > instance.. X1 is loadbalance, X2 is memory scalability, X3 is
> processor
> > scalability, X4 is complexity scalability, etc. As the terms can be 
> > complex scoring functions, this equation is also a sort of composite
> if
> > we'll express it in "patternese".
> > 
> >     Given that, I want to make focus on two terms that are important
> for
> > developers: 1. Content and 2. Form.
> > 
> >     For (non static) web applications (or online systems as 
> I like to
> say)
> > Seaside is a framework that irrefutably takes care of "the contents"
> and
> > solves basically and consistently "the form" using html and CSS. In
> the
> > form term I want to ponder a (sub)equation of two terms:
> > 
> >     1. Usability. The digital ergonomy. The empirical ease of use of
> the
> > systems. The facilities that your applications had to offer to end
> > (daily?) users.
> >     2. Cosmetic. The indumentary of the systems. Pure eye 
> candy makeup 
> > which users like to, as it's clothes, be able to renew often and
> flexibly
> > and numerously.
> > 
> >     For the contents I have no further comments because I consider
> Seaside
> > to be vanguardist and by far the best in it's field. So for me,
> content
> > has reached irrefutability. This means that for the "sale" (final
> score
> > value) this term sells OK. Now.. for the form 
> (usability+cosmetic) we
> have
> > reached an acceptable scoring but I think I found a way in 
> wich we can 
> > improve those terms in a way in direction of form 
> (usability+cosmetic) 
> > irrefutable scores.
> > 
> >     Said that, the concrete purpouse is to evaluate Dojo javascript 
> > toolkit as being used for Seaside applications. (see:
> > http://dojotoolkit.org/)
> > 
> >     I read that Dojo is ready to be use from Ruby so I think that
> nothing
> > should stop us to use it also from Seaside. Seems to be that Dojo 
> > community has some support from IBM so this should weight 
> something in
> the
> > balance. A first look into the demos could show you nice form value.
> If
> > you take a look on the widgets in the API documentation, 
> try to forget 
> > cosmetic for a moment and see the usability that those 
> widgets have to 
> > offer (and I mean the contents and not how they made the 
> documentation 
> > interface). Take a look into the panes with draggeable 
> splitters for 
> > instance. That can't be done with css. CSS can't even give 
> us (yet) an 
> > appropiated general solution for elemental #north, #south, #center 
> > automatic layouts. To make that you end up using CSS hacks 
> that leads
> you
> > to have an early compromise with the page shape. This 
> deteriorates the 
> > "desktopability" of web applications.
> > 
> >     I don't know you but I found those widgets very good in 
> what they
> do
> > and I think that to have them in sum to seaside 
> applications will rise
> the
> > score of seaside solutions significantly.
> > 
> >     My experience shows that wrapping this toolkit should 
> lead us to a 
> > hierarchy as rich as any Smalltalk View hierarchy of a 
> Smalltalk that
> is
> > using native widgets. So this means coupling because the classes end
> up
> > wrapping system events and calls to build the views. Here there will
> be
> > Dojo events and Dojo calls to build up the windows (yes it can do
> windows
> > inside a page) in the browser. But the add of coupling will 
> be with a 
> > cross-platform javascript widgets framework so we won vanguardist
> widgets
> > smalltalkish way usable that work for lots of browsers in lots of
> OS's. So
> > with this choice we end up using javascript calls as the dlls (or
> > homologous) libraries calls of a native system (which is the browser
> in
> > this case).
> > 
> >     Finally, if a Seaside is about the "descktopability" of web 
> > applications, then Seaside+Dojo could be a good deal. Once the
> wrapping
> > it's done and maintained, It will modify the whole equation allowing
> the
> > whole score to raise more dramatically for the same development
> effort.
> > That will maintain Seaside and Smalltalk itself to the vanguard
> allowing
> > the creation of Smalltalk solutions of high real value. An 
> ammount of 
> > value that other web application frameworks could only dream about.
> > 
> >     Now the realistic questions:
> > 
> >         Why do you  or do you not found Dojo a convenient choice?
> >         Beside Scriptaculous, do you know another choice 
> than Dojo? it 
> > will lead us to where? how far?
> >         Do you admit that wrapping Dojo will lead us to a View
> hierarchy?
> >         Admiting that this frameworks are a View...
> >             Do you found Model-View-Controller can be used 
> in Seaside 
> > applications?
> >             Do you found Model-View-Presenter more suitable?
> >             Do you found another event-model-view glue more 
> convenient 
> > than those? which one? why?
> > 
> >     cheers,
> > 
> > Sebastian Sastre
> > 
> > 
> 
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside



More information about the seaside mailing list