[Seaside] Design of WAComponent(s)
renggli at gmail.com
Wed Mar 5 10:58:22 UTC 2008
> responsibility of components?". Add that you cannot have two trees on a page
> with different appearance (style) without some work, involving code
Of course you can have different looking trees on a single page, you
simply put them into a div-tag with a specific class/id.
> 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)
Maybe you want to the check the history of WATree in the mailing list?
Why it was put into Seaside-Core and why it will be gone in Seaside
The goal of WATree is to give a component for quick prototyping and as
such it is probably not useful for your specific needs.
> 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".
I guess most people start with one of the ready-made components and
use it until they hit the limits. And only then they start to subclass
or write their own widget.
Of course it would be nice if WATree was more configurable, but I
doubt a newbie would prefer it over the simplicity of WATree. Having
to provide several models for a working tree, reminds me of my worst
nightmares when looking at the code of students that use Swing JTable
for the first time.
It is so simple and quick to create my own widget that does exactly
what I need, why should I bother with a huge library that could do
everything after hours of configuration?
> So what do you think? Is there a project/plans in this direction? Did I
> violate the principles of Seaside?
There are several projects working on widget libraries. You mentioned
ShoreComponents. Scriptaculous-Components is another one, focusing on
widgets with AJAX interaction. Both approaches don't provide much more
than a few configuration blocks.
It certainly does not violate the principles of Seaside. It might be
worth to investigate how well this scales?
More information about the seaside