Carsten Ziegeler a écrit :
>
> Sylvain Wallez wrote:
> >
> > 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> !
> >
> Yes, this workaround is possible - but with the extra cost of internal
> processing which I wanted to avoid with my example above.
> To be honest, if I think about this, yes, a map:generate would be
> much better as a map:part! It would avoid some internal processings as well.
> Hmm, a map:transform - yes why not! Ok, just kidding.
> Yes, of course you're right that people always wanted more than
> is available. But I think this is not a reason why we should forbid
> putting a map:select inside a map:aggregate. Because if we forbid this,
> sometime people will ask for this and we are in the same situation.
OK. I see your point : you want to avoid the costly "cocoon:" recursive
call just for using a selector. We could allow "non-pipeline" statements
(i.e. match/select/act) and map:part as children of map:aggregate.
But allowing map:generate in map:part won't avoid a coslty part of
"cocoon:" which is the lookup of new pipelines. Also, this promotes
pipeline reuse (if you aggregate, the parts are likely to be reused).
> > > 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 ;)
> >
> Hey, very good memory!
;)
> > 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.
> >
> Yes, I noticed this when I looked at the sitemap.xsl. As far as I saw
> it should really be very easy to allow actions on the top-level again.
> So, I'm +1 on removing this restriction!
+1 also.
> Carsten
>
> > > 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]
