cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: CForms Transformer plans...
Date Thu, 14 Oct 2004 21:27:42 GMT
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/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

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.


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

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.


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


>>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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message