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.
> > 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! 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
