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.
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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
