cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Johnston <>
Subject Re: [cforms] fi:validation-errors in AJAX mode
Date Tue, 02 Aug 2005 15:08:06 GMT
On Tue, 2005-08-02 at 16:14 +0200, Sylvain Wallez wrote:
> Jason Johnston wrote:
> > Sylvain Wallez wrote:
> >
> >> Ugo Cei wrote:
> >>
> >>> Looks good to me. AFAIK, Ajax support works only with the template 
> >>> macros, so it might not make sense to add this feature to the 
> >>> transformer also. What is the orientation of the community towards 
> >>> the transformer/macros ambiguity? I'd like to have just one 
> >>> recommended implementation of this, so if macros are the way to go, 
> >>> what about deprecating the forms transformer? 
> >>
> >>
> >> Well, macros are more powerful because they allow to do more than 
> >> templating with the widgets. A straightforward example is conditional 
> >> templating, e.g. displaying "There are now contacts" rather than an 
> >> empty table. This is not possible with a transformer, unless we add 
> >> an expression language and some control structures which will make it 
> >> yet another programming-language-in-XML...
> >>
> >> OTOH, the transformer is useful when JXTG is not a option e.g. when 
> >> the generator is an XSP...
> >
> >
> > IIUC you can also use JX as a transformer, so wouldn't that cover this 
> > case?
> Because you should really avoid using JXTransformer if you want a 
> responsive application: this transformer basically feeds the JX 
> generator with the incoming SAX stream, meaning the template is full 
> reparsed and recompiled at each execution, which is highly inefficient.
> IMO, we should make this very prominent in the doc and discourage such 
> usage, or even deprecate this transformer.

Ah, I wasn't aware of that.  This should definitely be prominently

Would it be possible to use Cocoon's caching mechanism to improve this
situation, i.e. if all the pipeline stages prior to the JX transformer
are cacheable and valid, then a compiled JX template gets used?

> > Anyway... to Ugo's question, I believe (correct me if I'm wrong) that 
> > AJAX works regardless of whether the template is interpreted by JX or 
> > the FormsTemplateTransformer, since it's the widgets themselves that 
> > signal whether or not they have been updated by wrapping their SAX 
> > output in a <bu:replace>.
> Exactly.
> > Personally I usually use FormsTemplateTransformer for most forms, 
> > unless I know for sure I'm going to need the extra expressive power of 
> > JX. Mostly because I'm too lazy to jx:import the forms macros resource 
> > in every template.
> Hmm... the import is just a ctrl-c/ctrl-v away. Wow, this *is* lazyness :-)

You got me. ;-)

But now that you mention the performance problem associated with using
JX as a transformer, that's another (more valid) reason to keep using
FormsTemplateTransformer.  My pipelines often include transformations
(usually cacheable) prior to the point where form template elements get


View raw message