Tim Larson wrote:
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/widgetCan 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.
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.
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
handlers.
Interesting. Looks like it's much more than a new implementation of the forms transformer, in which case it would be good to place it either in the scratchpad as a starting point or in its own block.
<snip/>
Perhaps this would also be a good time to re-evaluate the separationThat'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).
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.
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.
Sure. In order to optimize things, we may categorize the validators to be able to identify cross-widget validators so that only these ones get called whenever the value does not change or is not set.
<snip/>
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.
Mmmh... with dynamic templates, the page layout may vary a lot from one request to the other, meaning the set of displayed widgets can change. The checks should therefore be done at every page display. However, this must be an optional feature, meaning it can be activated in the development phase and disabled in production, thus avoiding its overhead.
<snip/>
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.
Ouch. It sounds like a very complicated issue, requiring a lot of client-side logic to be developped. What about an intermediate solution that would consist in having a reduced template that only formats the <form> element and its content, or a subpart thereof that client-side logic would put in place of the corresponding element in the displayed page? This means a bit more work server-side, but requires little client-side logic and still has the benefit of avoiding a full page reload (no flicker nor lost scroll position). Think incremental/partial update of the page.
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.
Yup. I already thought about that but lacked time to implement it. We may have a set of hidden inputs that the Form object just blindly passes through during a roundtrip. This set of inputs will be defined by the styling as it's a view-only concern.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
