> 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> !
I already did some while ago ;) and I'm still not quite convinced why this is supposed to be bad (as the structure feels quite straight forward) The current way bloats the sitemap unnecessarily losing the demand of minimum verbosity (IMHO) > > 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. Cool! I'm really looking forward for this thing :) -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
