You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ramy Mamdouh <ra...@imkenberg.net> on 2003/10/16 17:33:27 UTC
[Woody] why the binding load and save was removed from Form ?
Hi all,
The elegancy of using the binding from the flow script on the javascript
Form object makes me ask:
- why the load() and save() methods (with all the necessary binding
object, uri, binding manager) are not in the Form (that's it,
org.apache.cocoon.woody.formmodel.Form) class?
This way, we can use the same simple way of binding from outside the
flow script, maybe from an ActionListener or something.
For me, with the help of the new event handling in woody, this can lead
to a minimum javascript code, and the flow would be mainly for, well,
flow stuff :)
If there's no objection on moving this functionality into the
org.apache.cocoon.woody.formmodel.Form class, I can make it and send a
patch.
--
Ramy Mamdouh Kamel
ramy@imkenberg.net
Re: Is a Form a Widget? (was Re: [Woody] why the binding load and
save was removed from Form ?)
Posted by 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
Re: Is a Form a Widget? (was Re: [Woody] why the binding load and
save was removed from Form ?)
Posted by 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
Is a Form a Widget? (was Re: [Woody] why the binding load and save
was removed from Form ?)
Posted by Marc Portier <mp...@outerthought.org>.
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/
mpo@outerthought.org mpo@apache.org
Re: [Woody] why the binding load and save was removed from Form ?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Marc Portier wrote:
> Sylvain Wallez wrote:
>
>> Ramy Mamdouh wrote:
>>
>>> Hi all,
>>>
>>> The elegancy of using the binding from the flow script on the
>>> javascript Form object makes me ask:
>>>
>>> - why the load() and save() methods (with all the necessary binding
>>> object, uri, binding manager) are not in the Form (that's it,
>>> org.apache.cocoon.woody.formmodel.Form) class?
>>
>>
>> Work in progress... Actually, I added them and later removed them
>> before committing.
>>
>> When writing the binding, Marc insisted on the fact that it was
>> important for them to be separated. But I think that, although this
>> is important from a processing point of view (load, then handle the
>> form, then save once the form is valid), this may be good to
>> integrate this in the processing code for a form.
>
>
> sorry for being late
> (cleaning up some stuff I was putting under the mat during GT
> preparation ;-) and catching up with all that is going on here is hard
> to combine)
>
> not that I think you guys need my blessing, yet still some clarification:
>
> the binding-methods were originally kept outside the form based on
> some misplaced modesty of making the 'binding' a real optional
> addition that could be cut out easily, as such the binding package
> would depend on the model package, but not also the other way around.
>
> this rather theoretical clean-ness can easily be set asside if as I
> understand now:
>
> 1/ binding is perceived generaly useful and on the correct abstraction
> level (guessing that the binding takes an 'OBJECT' to bind to, I guess
> there is nor more abstract we could do ;-)
Agree: Object is abstract enough ;-)
> 2/ it fits more the natural understanding of the form to look at
> setting its values from the back-end side 'binding' to be on par to
> setting its values from the end-user perspective
>
>> 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()).
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.
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.
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".
Going back to your "composite widget" concern, we can consider that a
Form contains a root "CompositeWidget" (does not exist yet) that holds
the first-level widgets of the form.
>>> This way, we can use the same simple way of binding from outside the
>>> flow script, maybe from an ActionListener or something.
>>
>>
>> Yeah, and also have some (not yet implemented) processing-phase
>> listeners be triggered upon load and save.
>
>
> ah, more events, you mean?
>
> makes sense, and offers a great additional reason to look at binding
> more as 'a natural intrinsic feature' of the form rather then an
> optional side-track (which was the original reasoning)
Exactly.
>>> For me, with the help of the new event handling in woody, this can
>>> lead to a minimum javascript code, and the flow would be mainly for,
>>> well, flow stuff :)
>>>
>>> If there's no objection on moving this functionality into the
>>> org.apache.cocoon.woody.formmodel.Form class, I can make it and send
>>> a patch.
>>
>>
>> Please do.
>
>
> sure enough. and looking forward to it...
> (although with the current time I can spend reading up, this will lead
> to me needing a tutorial on woody-binding in the near future ;-))
I can do that ;-)
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: [Woody] why the binding load and save was removed from Form ?
Posted by Timothy Larson <ti...@yahoo.com>.
--- Marc Portier <mp...@outerthought.org> wrote:
> Sylvain Wallez wrote:
> > 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?)
I have written a "Struct" widget that would fill this need for a composite
pattern, but I do not yet have an opinion on the question of whether the form
should be a widget or not.
Expect a patch set pretty soon for "Struct", "Union", "Class", and "New" widgets.
--Tim Larson
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Re: [Woody] why the binding load and save was removed from Form ?
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
> Ramy Mamdouh wrote:
>
>> Hi all,
>>
>> The elegancy of using the binding from the flow script on the
>> javascript Form object makes me ask:
>>
>> - why the load() and save() methods (with all the necessary binding
>> object, uri, binding manager) are not in the Form (that's it,
>> org.apache.cocoon.woody.formmodel.Form) class?
>
>
>
> Work in progress... Actually, I added them and later removed them before
> committing.
>
> When writing the binding, Marc insisted on the fact that it was
> important for them to be separated. But I think that, although this is
> important from a processing point of view (load, then handle the form,
> then save once the form is valid), this may be good to integrate this in
> the processing code for a form.
>
sorry for being late
(cleaning up some stuff I was putting under the mat during GT
preparation ;-) and catching up with all that is going on here is hard
to combine)
not that I think you guys need my blessing, yet still some clarification:
the binding-methods were originally kept outside the form based on some
misplaced modesty of making the 'binding' a real optional addition that
could be cut out easily, as such the binding package would depend on the
model package, but not also the other way around.
this rather theoretical clean-ness can easily be set asside if as I
understand now:
1/ binding is perceived generaly useful and on the correct abstraction
level (guessing that the binding takes an 'OBJECT' to bind to, I guess
there is nor more abstract we could do ;-)
2/ it fits more the natural understanding of the form to look at
setting its values from the back-end side 'binding' to be on par to
setting its values from the end-user perspective
> 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?)
>> This way, we can use the same simple way of binding from outside the
>> flow script, maybe from an ActionListener or something.
>
>
>
> Yeah, and also have some (not yet implemented) processing-phase
> listeners be triggered upon load and save.
>
ah, more events, you mean?
makes sense, and offers a great additional reason to look at binding
more as 'a natural intrinsic feature' of the form rather then an
optional side-track (which was the original reasoning)
>> For me, with the help of the new event handling in woody, this can
>> lead to a minimum javascript code, and the flow would be mainly for,
>> well, flow stuff :)
>>
>> If there's no objection on moving this functionality into the
>> org.apache.cocoon.woody.formmodel.Form class, I can make it and send a
>> patch.
>
>
>
> Please do.
sure enough. and looking forward to it...
(although with the current time I can spend reading up, this will lead
to me needing a tutorial on woody-binding in the near future ;-))
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
Re: [Woody] why the binding load and save was removed from Form ?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ramy Mamdouh wrote:
> Hi all,
>
> The elegancy of using the binding from the flow script on the
> javascript Form object makes me ask:
>
> - why the load() and save() methods (with all the necessary binding
> object, uri, binding manager) are not in the Form (that's it,
> org.apache.cocoon.woody.formmodel.Form) class?
Work in progress... Actually, I added them and later removed them before
committing.
When writing the binding, Marc insisted on the fact that it was
important for them to be separated. But I think that, although this is
important from a processing point of view (load, then handle the form,
then save once the form is valid), this may be good to integrate this in
the processing code for a form.
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.
> This way, we can use the same simple way of binding from outside the
> flow script, maybe from an ActionListener or something.
Yeah, and also have some (not yet implemented) processing-phase
listeners be triggered upon load and save.
> For me, with the help of the new event handling in woody, this can
> lead to a minimum javascript code, and the flow would be mainly for,
> well, flow stuff :)
>
> If there's no objection on moving this functionality into the
> org.apache.cocoon.woody.formmodel.Form class, I can make it and send a
> patch.
Please do.
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