Sylvain Wallez wrote:
Jason Johnston wrote:
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.
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.
Getting more familiar with this code, it actually looks like I was
wrong about where the bu:replace gets created. I thought it was done
in the widget's generateSaxFragment method, but it actually is done in
the template layer. And it looks like it's only implemented so far in
the JX macros, not in FormsTemplateTransformer. So it looks like Ugo
was right.
Yep. But the code in JXMacrosHelper could be reused and/or refactored to
be used in the TemplateTransformer.
The only AJAX-related code I can find in the Widget (formmodel)
classes is in AbstractWidget.generateSaxFragment(), where it creates
an fi:placeholder if the widget is invisible. It seems odd to me to
have this here, perhaps it would better belong in the template layer
as well.
Hmm... the idea behind this is to ensure that the view layer, whatever
it is, has no possibility to produce the XML representation of a widget
if that widget's state prevents it to be displayed.
And that would still be the case, but the production of fi:placeholder
(which is an AJAX-only implementation detail, right?) would be moved
into the view layer. Keep the "if", move the "else".
- Re: [cforms] fi:validation-errors in AJAX mode Jason Johnston
-
