cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [Woody] why the binding load and save was removed from Form ?
Date Wed, 22 Oct 2003 08:43:42 GMT
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 
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) 


>>> 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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message