Carsten Ziegeler a écrit :
> 
> Hi,
> 
> I currently run into the problem that I created pipelines which I
> thought were possible, but currently are not support by Cocoon:
> 
> It is not possible to nest anything other than a map:part into
> a map:aggregate, so the following doesn't work:
> <map:aggregate>
>   <map:select type="test">
>     <map:when test="a">
>       <map:part src="a"/>
>     </map:when>
>     <map:otherwise>
>       <map:part src="b"/>
>     </map:otherwise>
>   </map:select>
>   <map:part src="constant"/>
> </map:aggregate>
> 
> Is this a bug or is this by design?
> My personal opinion is, that this should be possible.

I guess this is by design. The above can be written as follows :

<map:match pattern="variablepart.xml">
  <map:select type="test">
    <map:when test="a">
      <map:generate src="a"/>
    </map:when>
    <map:otherwise>
      <map:generate src="b"/>
    </map:otherwise>
  </map:select>
  <map:serialize/>
</map:match>

<map:match pattern="...">
 <map:aggregate>
   <map:part src="cocoon:/variablepart.xml"/>
   <map:part src="constant"/>
 </map:aggregate>
</map:match>

It is sure less readable, but if we allow statements other than
<map:part> in <map:aggregate>, people will certainly soon ask for
<map:generate> or <map:transform> inside <map:part> !

> Another restriction we currently have is already entered as a bug with
> the number 4357: An Action is not possible as a root element inside
> a map:pipeline, only map:match can be a used as a root element.
> So here again, is this by design?

This was allowed before we faced the 64 kbytes bytecode limit in the
generated class. IIRC, you were the one that faced this ;)

We then decided to break the generated code into submethods based on
map:pipeline/map:match which as a side effect forbids any other
top-level construct.

So this restriction is not "by design", but "by implementation" ! The
TreeProcessor (still have to write views for it to be finished) doesn't
have this limitation.

> I think we shouldn't make such restrictions. But at least if we make
> these restrictions we should document them.
> 
> Regards,
> Carsten
> 

Sylvain

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to