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/ [EMAIL PROTECTED] [EMAIL PROTECTED]
