[Seaside] Design of WAComponent(s)

[Andreas T ö nne]

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)