convenientthan Scriptaculous for Seaside solutions
boris at deepcovelabs.com
Thu Apr 26 17:38:39 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,
config: [:v | v close: true]);
yuipanel: component config: block
onFailure: ((SUStream new)
callback: [:render |
| dialog |
dialog := (Seaside.YUIPanel new)
block value: dialog.
dialog renderContentOn: render];
So it's really up to you to decide what tool is right for the job.
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
boris at deepcovelabs.com
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
> -----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'
> 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
> 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:
> Each term is a function of value (scoring) of different domains:
> instance.. X1 is loadbalance, X2 is memory scalability, X3 is
> scalability, X4 is complexity scalability, etc. As the terms can be
> complex scoring functions, this equation is also a sort of composite
> we'll express it in "patternese".
> Given that, I want to make focus on two terms that are important
> developers: 1. Content and 2. Form.
> For (non static) web applications (or online systems as I like to
> Seaside is a framework that irrefutably takes care of "the contents"
> solves basically and consistently "the form" using html and CSS. In
> form term I want to ponder a (sub)equation of two terms:
> 1. Usability. The digital ergonomy. The empirical ease of use of
> 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
> and numerously.
> For the contents I have no further comments because I consider
> to be vanguardist and by far the best in it's field. So for me,
> has reached irrefutability. This means that for the "sale" (final
> value) this term sells OK. Now.. for the form (usability+cosmetic) we
> 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.
> toolkit as being used for Seaside applications. (see:
> I read that Dojo is ready to be use from Ruby so I think that
> 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
> balance. A first look into the demos could show you nice form value.
> 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
> 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
> and I think that to have them in sum to seaside applications will rise
> 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
> using native widgets. So this means coupling because the classes end
> wrapping system events and calls to build the views. Here there will
> Dojo events and Dojo calls to build up the windows (yes it can do
> inside a page) in the browser. But the add of coupling will be with a
> smalltalkish way usable that work for lots of browsers in lots of
> homologous) libraries calls of a native system (which is the browser
> this case).
> Finally, if a Seaside is about the "descktopability" of web
> applications, then Seaside+Dojo could be a good deal. Once the
> it's done and maintained, It will modify the whole equation allowing
> whole score to raise more dramatically for the same development
> That will maintain Seaside and Smalltalk itself to the vanguard
> 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
> Admiting that this frameworks are a View...
> Do you found Model-View-Controller can be used in Seaside
> Do you found Model-View-Presenter more suitable?
> Do you found another event-model-view glue more convenient
> than those? which one? why?
> Sebastian Sastre
More information about the seaside