[Seaside] Design of WAComponent(s)

Wed Mar 5 14:35:04 UTC 2008

Hi Andreas,

	I think is not MVC vs. Seaside. I think Seaside is a platform which
provides solutions to a certain point but also allows you to take that point as
a start of something bigger. I'm taking advantage of Seaside to make one by one
a more complex (an powerful) kind of components which makes the developer to
feel like programing widgets in a desktop application. In fact pretty much
Dolphin Smalltalk style which is MVP, a variation of MVC. 

	For me is no discussion to make because it's working so well. I even
make the javascript part on this components to be inheritable, beacouse it's
supported by the smalltalk hierarchy, and dinamically updateable (after an
updater you can make a DOM element to behave differently). And is so easy that
the tooltip I saw being discussed will be easier and more powerful to make from
seaside itself than to wrap that ProtoTip.

	cheers,

Sebastian Sastre

> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre 
> de Andreas T ö nne
> Enviado el: Miércoles, 05 de Marzo de 2008 07:30
> Para: seaside at lists.squeakfoundation.org
> Asunto: [Seaside] Design of WAComponent(s)
> 
> Hello!
> 
> Inspired by my own work needs on Seaside 2.8 on VisualWorks 
> 7.6 and also by
> the recent discussion on MVC vs. Seaside I like to start a 
> discussion about
> forming a generalization of components, giving them more 
> inner structure and
> more uniformity. A more detailed model of WAComponent. 
> Possibly there are
> projects running in the Squeak world that I do not know of 
> and that make
> this discussion unnecessary. In that case I would be grateful for any
> pointers!
> 
> To illustrate where I am coming from, let me pick one of the 
> predefined
> components in the core: WATree. I picked this component because it is
> generally useful (a typical element of web applications) and 
> because it
> supports my ideas nicely.
> 
> The class comment says " WATree implements a tree menu, which supports
> nesting, collapsing and expanding. Prefixes items with "+/-" 
> to indicate
> items that can be expanded/collapsed."
> 
> If you look at the implementation then you see that it has several
> fundamentally different tasks:
> 
> - provide a tree fascade over an arbitrary object
> - manage the selection in this tree model
> - manage the tree expansion/collapse model of the tree
> - create the XHTML presentation of the tree model
> - (indirectly) provide controller behavior by letting you 
> place callbacks in
> the select: block
> 
> Also the view part is rather inflexible in the XHTML 
> generated: it builds an
> unordered list with constant css classes for the elements.
> 
> I am an old school Smalltalker who values clear models and 
> responsibilities.
> When I looked at this component, my first thought was "this 
> is a bit much
> for one class" and the second one was "what is exactly the intended
> responsibility of components?". Add that you cannot have two 
> trees on a page
> with different appearance (style) without some work, involving code
> duplication.
> 
> If we split this class into independent concepts that can be
> recombined/varied in useful ways then we get:
> - a model of a tree
> - a model of the visual appearance (expand/collapse) of the tree model
> - a XHTML generator
> = a domain logic combining the above three with selection and 
> interface to
> the application logic (callback)
> 
> One can put the collapsed/expanded information into the 
> domain logic object,
> which means a new WATree model will be constructed from a 
> tree model and a
> matching XHTML generator. How is this useful?
> 
> - stays object-oriented on the model side by encapsulating 
> the tree model
> instead of exposing it in blocks
> - allows different renderings of such tree expansion state. 
> Unordered lists
> of buttons, labels and associated children are fine but one option
> - allows more configuration control on the styles attached 
> (ok this could be
> a simple useful addition to WATree in its current shape too)
> - when modeled right it allows to share XHTML rendering among 
> components
> 
> Interestingly, the shore components example has its own, 
> rather differently
> implemented tree component with a dedicated model of the visual tree
> appearance and using tables instead of unordered lists. So by 
> not providing
> the developer with a Seaside Component Framework, a lot of unnecessary
> development work and code duplication is taking place. I 
> think the message
> to new developers should be "pick a component and configure it to your
> needs" instead of "look at the examples and program one for yourself".
> 
> So what do you think? Is there a project/plans in this 
> direction? Did I
> violate the principles of Seaside?
> 
> Andreas
> 
> -- 
> Andreas Tönne
> Lead Consultant
> Cincom Systems GmbH & Co. oHG
> Tel.: +49 6196 9003 100
> Mobile: +49 172 6159272
> Fax: +49 6196 9003 270
> 
> Geschäftsführer/Managing Directors: Thomas M. Nies, Gerald L. Shawhan
> oHG mit Sitz/based in Schwalbach/Ts. (Amtsgericht Königstein/Ts. HRA
> 2653)
> Pers. haftender Gesellschafter/Partner liable to unlimited extent:
> Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht Königstein/
> Ts. HRB 5069)
> 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside