cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Johnston <coc...@lojjic.net>
Subject Re: [cforms] fi:validation-errors in AJAX mode
Date Thu, 04 Aug 2005 14:20:43 GMT
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".

Mime
View raw message