Jonas Ekstedt wrote: <snip/>
I tried to implement a RequestProcessor for CForms just to see if it was doable.
Cool!
It doesn't yet work quite the way you envision with converters and renderers as I wanted the change to be as minimal as possible.
Seems reasonable, it is much better to work in steps, than trying to introduce everything at once. Easier to get feedback that way also. Think that the rendering/convertion stuff could need some more thought before implementation also.
Instead it uses some of the existing widget methods for population. I've attached two patches if you want to try it out (I'm a bit of a novice with subversion and creating patches so they might not work).
Please submit your patch to Bugzilla so that it doesn't get lost among all the mails. See http://wiki.apache.org/cocoon/ProjectManagement for instructions. It is also good to have a Bugzilla entry so that you can add refinements to your code there.
Your subversion patches seemed to work except for that I had to add the directory samples/widgetpopulation and add it in subversion to make it possible to apply the samples patch.
As far as I can tell the changes are backwards compatible (the other samples seems to work anyway).
Instead of the original RequestProcessor there is instead a WidgetPopulator. It works similar in that it is added as an attribute to the request in Form.js.
Why is it added to the Request, wouldn't it be more natural to bind it to a variable in the flowscript instead?
Then during rendering, each widget that is rendered will try to register itself on this WidgetPopulator (this is done in jx-macros.xml). Currently only widgets of type Action, BooleanField, Field, MultiValueField, RowAction, Submit and Upload will be registered. I don't really know how to handle AggregateField and haven't tested if it suffices to register it's child widgets only.
RT: could this mechanism be used to automatically set the widget states for multi page forms?
IIRC your main reason for the WidgetPopulator with render time registration, was to get safe model loading without having to write an excplit form definition.
But as long as it is bounded to the widget hierarchy so that the widget hierarchy cannot be replaced by another model, does the widget populator by us something in its current form?
After the form has been submitted the list of registered widgets is sent to Form.process(). Then instead of recursively populating all widgets the form widget will iterate through the list of registered widgets and call readFromRequest() on each.
Currently the WidgetPopulator is simply a holder of widgets that should be populated and it is the Form that does the population. I did it this way because the CForm code was a bit overwhelming and it was hard to get a grip on what side effects would occur if population was lifted out of the Form. Preferably population should be done in the WidgetPopulator.
Agree that CForms is a little bit overwhelming. You can find an example of how to populate a widget from SAX input here:
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/forms/java/org/apache/cocoon/forms/util/XMLAdapter.java?view=auto
I don't know what effect lifting out the population would have on event handling and validation. Hopefully someone with more knowledge about the CForm life cycle read this and explains.
You can find some info about the CForm life cycle here: http://wiki.apache.org/cocoon/WoodyRefactoring
Thanks for the patch!
/Daniel
