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/...

[Jeremy Quinn]

On 14 Nov 2006, at 12:46, Sylvain Wallez wrote:

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 ;)





. . .
<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:when>
     <map:otherwise>
       <map:serialize type="xml"/>
     </map:otherwise>
   </map:select>
 </map:when>
. . .



Any suggestions for reducing this complexity ?

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:transform src="resource://org/apache/cocoon/forms/ resources/IframeTransport-bu-styling.xsl"/> <map:serialize type="xhtml"/><!-- this is REALLY important --> If iFrameIOTransport is being used, then the BU response needs to be different XML and have a different serializer. 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?

Hi Sylvain :)

Do we have virtual pipeline components yet ?






thanks

regards Jeremy

I do not know much about them ..... AFAIU resources can only be called from the sitemap in which they exist ..... virtual pipeline components are a concept similar to resources ? It looks like I will be adding a system-level sitemap for CForms, to handle stuff like upload progress status ..... my plan is to have it compiled into the CForms jar, but I have never tried running a sitemap from that type of source before ..... has anyone tried to mount a sitemap from (eg.) resource://org/apache/cocoon/forms/ resources/system/sitemap.xmap before ?

smime.p7s
Description: S/MIME cryptographic signature