cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [cforms] fi:validation-errors in AJAX mode
Date Thu, 04 Aug 2005 13:47:10 GMT
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.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message