cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject CForms Transformer plans...
Date Wed, 13 Oct 2004 13:58:33 GMT
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.

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.  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.

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...

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.  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.

--Tim Larson

View raw message