cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: CForms Transformer plans...
Date Thu, 14 Oct 2004 15:29:27 GMT
On Thu, Oct 14, 2004 at 09:04:25AM +0200, Sylvain Wallez wrote:
> 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.

I am wanting to create a generic template/transformation engine,
as Bertrand phrased it on #cocoon, "something between XSLT and
full-blown java transformers", and I want it to perform global
optimization over a sequence of template/transform steps.  And
for its first use-case it needs to have a set of cforms template
handlers loaded into it, as well as some standard transformation

You are right that the current design of transformer could not
get the compile+cache behaviour, but we could split this new code
out as a new generator and/or transformer getting the template
from a src parameter (with the option of using a cocoon:/ source).
The generator variant would be similar to the current forms
transformer; for example, pulling its data from the form object
and possibly other objects, while the transformer varient would
just happen to have one more input available (the sax stream).

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

I think this makes sense, don't change the value if there is no value
to change.  But we would still have to fire any validation rules in
case there were any cross-widget validation rules present.

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

Good catch, I missed that widget attributes already provide a good
place to store this present-in-template info :)
The missing-required-fields check is more expensive if we have to do
it on every template application, but that may be acceptable.

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

It is a "little" more complex than that...a client-side update of one
widget may trigger changes to multiple subtrees of widgets, meaning
that we may need to process multiple subtree-roots, and then have
client js that splits the resulting xml back out.  We also have to
make sure we put enough id info in the markup surrounding the widgets
that we can identify it to change it based on the data returned by
the xmlhttprequests.

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

Right, we also need to have normal POST's as a fallback, and it would
be nice in that case to record and reset the scroll position and any
input focus to give a similar, user-friendly experience.

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

See above.

> >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.
> >
> >WDYT?
> 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 
> xmlhttprequest.
> Sylvain

--Tim Larson

View raw message