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. WDYT? --Tim Larson
