Return-Path: 
 <dev-return-90751-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 62673 invoked from network); 14 Nov 2006 12:46:51 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 14 Nov 2006 12:46:50 -0000
Received: (qmail 28018 invoked by uid 500); 14 Nov 2006 12:46:58 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 27952 invoked by uid 500); 14 Nov 2006 12:46:58 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 27941 invoked by uid 99); 14 Nov 2006 12:46:58 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Nov 2006 04:46:58 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Received: from [84.96.21.10] (HELO trinity.anyware-tech.com) (84.96.21.10)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Nov 2006 04:46:45 -0800
Received: from localhost (localhost [127.0.0.1])
	by trinity.anyware-tech.com (Postfix) with ESMTP id 722A84D0FDB
	for <dev@cocoon.apache.org>; Tue, 14 Nov 2006 13:46:23 +0100 (CET)
Received: from trinity.anyware-tech.com ([127.0.0.1])
	by localhost (trinity.anyware-tech.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 24721-01-3 for <dev@cocoon.apache.org>;
	Tue, 14 Nov 2006 13:46:10 +0100 (CET)
Received: from [10.0.1.27] (poukram.anyware [10.0.1.27])
	by trinity.anyware-tech.com (Postfix) with ESMTP id 5DE004D58B3
	for <dev@cocoon.apache.org>; Tue, 14 Nov 2006 13:46:04 +0100 (CET)
Message-ID: <4559BA99.1060701@apache.org>
Date: Tue, 14 Nov 2006 13:46:17 +0100
From: Sylvain Wallez <sylvain@apache.org>
User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025)
MIME-Version: 1.0
To: dev@cocoon.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/...
References: <20061112152809.C7C4E1A9846@eris.apache.org>
 <4557B126.2050201@agssa.net>
 <50627406-7AA7-4D8F-8DD2-48D981B02CBC@apache.org>
In-Reply-To: <50627406-7AA7-4D8F-8DD2-48D981B02CBC@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Debian amavisd-new at anyware-tech.com
X-Virus-Checked: Checked by ClamAV on apache.org

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