[Seaside] Pondering if Dojo javascript toolkit is more convenient than Scriptaculous for Seaside solutions

Philippe Marschall philippe.marschall at gmail.com
Thu Apr 26 21:23:52 UTC 2007


2007/4/26, Sebastian Sastre <ssastre at seaswork.com>:
>
>
> 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?

MooTools
http://mootools.net/

Cheers
Philippe

> 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