cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Sat, 06 Nov 2004 15:13:25 GMT
I'll give some short comments now. Hope to find time to give a more 
detailed view about multiform handling and other stuff later.

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

Mime
View raw message