Re: Is a Form a Widget? (was Re: [Woody] why the binding load and save was removed from Form ?)

[Sylvain Wallez <sy...@apache.org>]

Marc Portier wrote:

>
>
> 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 


What do you mean? Drawing is a difficult experience for him? The this 
makes the subliminal sign even more valuable ;-D

>> 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 :-) 


No no! We are in the process of distinguishing the root widget (the 
Form) and the object that processes this root widget and its children.

<snip/>

> 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)


That's the idea. Furthermore, we can consider that the FormProcessor is 
a controller-only object and that the top-level Form widget is the 
object that is passed to the view. This distinction may also allow to 
have several forms in a page by having a single FormProcessor manage 
several root widgets?

OTOH, we also have to consider that many widgets (e.g. Field) reference 
their form to e.g. throw events. If we split Form, does Field have to 
know Form or FormProcessor? Event handling seems more to be the 
FormProcessor's responsibility, but having the widgets knowing the 
processor doesn't seem good to me.

Well, well...

> <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? ;-) 


Manoeuvring? Nope, I'm just explaining my own thoughts and doubts, and 
you happen to share them!

But it seems that even splitting Form into processor and root widget may 
answer some of the current concerns, it is very likely to bring other 
ones. So let's keep it as is now.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: Is a Form a Widget? (was Re: [Woody] why the binding load and save was removed from Form ?)

[Marc Portier <mp...@outerthought.org>]

Sylvain Wallez wrote:

> Marc Portier wrote:
> 

<snip />


>>> 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 :-) 
> 
> 
> 
> No no! We are in the process of distinguishing the root widget (the 
> Form) and the object that processes this root widget and its children.
> 

yep, I got to understand that somewhere down the line ;-)

> <snip/>
> 
>> 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)
> 
> 
> 
> That's the idea. Furthermore, we can consider that the FormProcessor is 
> a controller-only object and that the top-level Form widget is the 
> object that is passed to the view. This distinction may also allow to 
> have several forms in a page by having a single FormProcessor manage 
> several root widgets?
> 
> OTOH, we also have to consider that many widgets (e.g. Field) reference 
> their form to e.g. throw events. If we split Form, does Field have to 
> know Form or FormProcessor? Event handling seems more to be the 
> FormProcessor's responsibility, but having the widgets knowing the 
> processor doesn't seem good to me.
> 

why would event handling be the realm of the formprocessor?

as I see it, events are thrown by observables to observers when their 
state changes in a predefined way... taking this view the widgets and 
their root seem more appropriate to be the sources of these events 
(since it's their state?) then the processor, no?

but maybe I'm missing something here?


> Well, well...
> 
>> <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? ;-) 
> 
> 
> 
> Manoeuvring? Nope, I'm just explaining my own thoughts and doubts, and 
> you happen to share them!
> 

as most of the times in fact
(but you did notice my smiley, right?)

> But it seems that even splitting Form into processor and root widget may 
> answer some of the current concerns, it is very likely to bring other 
> ones. So let's keep it as is now.
> 

have to admit I haven't got much spare do-time ATM to take it up, but 
stopping thoughts is something I can't do...

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org