cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonas Ekstedt <ekst...@ibg.uu.se>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Fri, 05 Nov 2004 23:44:55 GMT
On Thu, 2004-11-04 at 23:42 +0100, Daniel Fagerstrom wrote:

> >>I prefer the request processor idea to the current form population where 
> >>each widget reads it data from the request object. The current scheme 
> >>makes CForms unecesarily bound to the request parameter model of input 
> >>data. With a request processor that is reponsible to write input data 
> >>into the form model, it would be easy to plug in a different request 
> >>processor if one gets xml input from a browser that implements XForms, e.g.
> >  
> > I think it would be quite easy to make this change to CForm.
> 
> So do I, although I havn't studied the details in CForms for a while. I 
> guess it can be done in a completely back compatible way. A request 
> processor, a convertor/renderer and a view adapter needs to be written. 
> Then one just don't use the readFromRequest and generateSaxfragment any 
> more. There might be subtilities in the state sequence within widgets 
> that complicates thins though.

I tried to implement a RequestProcessor for CForms just to see if it was
doable. 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.
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). 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. 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.

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.

// Jonas

Mime
View raw message