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

[Boris Popov]

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,

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