cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: CForms Transformer plans...
Date Thu, 14 Oct 2004 07:04:25 GMT
Tim Larson wrote:

>I plan to modify the forms transformer to match the builder/widget
>compiled model like the form model and bindings currently use.
>This will allow caching of compiled templates, and allow for
>more (possibly optional) complex template analysis during the
>build/compile stage, such as finding missing "required" widgets.

Can you elaborate on "caching of compiled templates"? With the 
transformer, the template is defined by the generator's output and 
therefore the transformer has no means to cache it.

>Perhaps this would also be a good time to re-evaluate the separation
>of concerns between the form model and the template concerning the
>choice of which widgets to display on any particular page.
>Right now the form model controls this, because widgets not present
>in the template get reset to null.

That's something I really think we should change: a widget should change 
its value if and only if it's present in the request. The only problem 
is for booleanfields since HTML sends no parameter for unchecked inputs. 
An easy solution to this can be for the booleanfield styling to add an 
hidden field indicating the presence of the booleanfield widget in the 
form (i.e. set the value of "mybool" if the hidden "mybool.present" 
exists in the request).

>If we had compiled templates,
>then there would be a place to record which widgets were sent and
>thus which widgets would need to process their request parameters.
>Still thinking about how this would interact with "stateless" forms.

I don't see why we need compiled templates to allow this. Either with 
the current transformer and the JX macros, the view can flag (using a 
widget attribute) the widget it ouputs, and a check can be performed at 
the end of the template processing in search of missing required fields.

>We also want to be able to use xmlhttprequest to process updates to
>individual widgets and sets of widgets, as well as to update various
>markup or styling.  This implies that the "view" implementation for
>cforms needs to be able to process restricted collections of widgets
>and markup and have an xml format for communicating these updates
>to the client.  We have a good start toward this because our cforms
>templates are already structured to process widget by widget, but
>using these templates is very slow for interactive update of small
>parts of a page via xmlhttprequest, putting us at a significant
>disadvantage compared with more primitive client-side js solutions...

Well, using xmlhttprequest will always be slower than pure client-side 
behavior! But you're right that allowing finer grained update is needed 
(Ugo's xhrCarSelector is a good example of this). Generalizing this 
mechanism may IMO be simply achieved by augmenting the FormsGenerator, 
that currently dumps the full widget tree, by allowing it to dump only a 
particular widget subtree of a given form.

Within the form display loop, the choice between full-html rendering and 
partial tree dump could be made by examining the value of a request 
parameter indicating the subtree path that needs to be updated.

But the server-side behavior is the easy part of it. We have a lot of 
client-side code to write (will all cross-browser issues it implies) to 
make this a reality. We should also be aware that not all browsers 
support xmlhttprequest: we use CForms on PDAs where it doesn't exist.

>What if we modify the forms transformer as described above and make
>it more a general transformation engine that can perform work similar
>to an xslt processor?  Then we could feed it a pipeline of transforms
>to process and it could do global optimization to the pipeline during
>its build/compile stage.  A sample optimization would be replacing
>transforms like A->B->C->D->E with A->E, allowing more clear, modular
>transform steps to be created by the programmer, while still allowing
>the "compiled" system to run very efficiently.

Mmmmh... again, I don't see how a transformer could compile its 
template, that template being defined by the runtime production of the 
previous component in the pipeline. Did I missed something?

>Another optimization
>would be detecting what information later transformation steps need
>and automatically registering listeners/counters/aggregators to
>earlier transformation steps to record this info to prevent having to
>do whole-DOM searches like the current xsl stylesheets perform.

Well, I don't really understand the template compilation thing, and 
think there are simple solutions with what we have today to check 
missing required fields and perform some partial form update with 


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message