cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: svn commit: r473974 - in /cocoon/trunk/blocks: cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/apache/cocoon/ajax/resources/js/ cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/ cocoon-forms/cocoon-forms-impl/src/...
Date Tue, 14 Nov 2006 12:46:17 GMT
Jeremy Quinn wrote:
>
> On 12 Nov 2006, at 23:41, Antonio Gallardo wrote:
>
>> Hi Jeremy,
>>
>> Nice work. Please look into the small issues below:
>
> <snip/>
>
>> We use 4 spaces for tabs.
>
> Ugh! I hate the 4 spaces rule ;)
>
>>>
>> Encoding typo? Please review your subversion settings.
>
> I think it was a UTF-8 Byte Order Mark, removed .....
>
> I had also forgotten to make the Upload Form sample use Ajax, doh ;)
>
> One thing I forgot to mention in my notes for these changes is the 
> rendering pipeline .....
>
> The pipeline for rendering JXMacro-based forms now has to adapt itself 
> to whichever Dojo Transport is being used, as the BrowserUpdate 
> response has to be different for each one :
>
> . . .
> <map:select type="ajax-request">
>   <map:when test="true">
>     <map:select type="request-parameter">
>       <map:parameter name="parameter-name" value="dojo.transport"/>
>       <map:when test="iframe">
>         <map:transform 
> src="resource://org/apache/cocoon/forms/resources/IframeTransport-bu-styling.xsl"/>

>
>         <map:serialize type="xhtml"/><!-- this is REALLY important -->
>       </map:when>
>      <map:otherwise>
>        <map:serialize type="xml"/>
>      </map:otherwise>
>    </map:select>
>  </map:when>
> . . .
>
> If iFrameIOTransport is being used, then the BU response needs to be 
> different XML and have a different serializer.
>
> Any suggestions for reducing this complexity ?
>
> Maybe the BrowserUpdateTransformer could differentiate depending on 
> the Transport, to save having the extra XSLT Transformation?
>
> Sylvain suggested a BrowserUpdateSerializer, that could switch between 
> XML and XHTML depending on the Transport.

Yup, the idea of hard-coding it into a serializer is to avoid requiring 
people to copy/paste this (complex) snippet which is required plumbing 
they should normally neither modify nor care about.

Or is there a way to define this as a system-provided virtual serializer?

Sylvain

-- 
Sylvain Wallez - http://bluxte.net


Mime
View raw message