Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
<snip agreement="on the previous topic of this thread" />
Agree: Object is abstract enough ;-)
Well, I did try to get it more generic... hm, guessing one can't succeed always ;-)
[now, on the side-track question that emerged]
And also, considering the very unique features of the Form class compared to other widgets, I'm wondering if it should be a widget at all.
binding itself benefits from the implied 'composite' pattern this approach is introducing
care to share more practical reasons to change it?
(pls understand: I'm open to changing it, but if we do, I would like us to keep the composite pattern allive by introducing some wrapping/wrapped widget that holds all the widgets of the form?)
The Form handles the various request processing phases (readFromRequest, event handling, validate) through its process() method, and forbids external code to call these processing phase methods on itself (see Form.readFromRequest() and Form.validate()).
yep, the fact that it has a reference to the widget-tree is more of a detail if presented like this
We also have to consider other existing "subliminal signs" about this:
- WoodyTransformer and WoodyGenerator explicitely use the Form class to get the form and not Widget.
- Bruno's drawing at http://wiki.cocoondev.org/Wiki.jsp?page=WoodyIntro explicitely depicts the Form class as separated from the Widget tree.
well, I wouldn't take that picture as real strong evidence:
I happen to personally know the artist who makes them, and the state he's in when doing so :-O
I'm very sensible to these signs, because they show the subconscious understanding of a concept, which is often more accurate that the conscious one which has gone through many filters. An example of this is when you often make the same typo for a method or attribute name: this is a sign that the name is badly chosen and that it should be changed.
makes sense, and you know I share your concern there
Now what Form shares with widgets is getWidget() (and not getParent(), since it has intrinsically no parent) and generateSAXFragment, and provides many more methods. So I'm not sure that a form *is* a widget. It's rather more a kind of "widget tree processor".
hence your almost side-wise comment on the 'name-change' ?
I have to say this is a bit funny: we just voted to rename 'woody' to 'cocoon forms' and now we are dicussing the remove the only reference still in the code to the actual 'FORM' word :-)
so taking up your subliminal line of defense: the fact that we refer to this as the 'form' framework kinda indicates there should be room for the concept at least... (and it should be a stronger reference then the fact that it is about <html:form> IMHO)
and putting myself at a "I don't know internals distance" (the spot where fresh users are) it really feels like a form IS a widget, or in other words: I would be astonished if it is not.
Going back to your "composite widget" concern, we can consider that a
(wel, I didn't want to overdo this concern, but it does amount to some coding elegance at no cost IMHO)
Form contains a root "CompositeWidget" (does not exist yet) that holds the first-level widgets of the form.
well, reading it all together: maybe we have indeed a WidgetTreeProcessor (although it can be FormProcessor, no?) and we could at least call the method getForm() to get a hold of that 'root-composite-widget?'
what I try to say is that I think I understand that the 'Form' as is coded now doesn't really qualify for the term 'widget'
so the consensus is maybe in understanding that
1/ a Form _is_ a Widget (as in the root-of-the-tree)
2/ the current Form should be renamed since it isn't fitting the bill any more
(BTW I don't like FormProcessor either, haven't got a decent alternative though)
<snip more_agreement="on binding being an intrinsic aspect of widgets" />
euh, is it just a feeling or am I really at the very spot you manouvered me to? ;-)
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
