cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Allowed Sitemap Constructs
Date Thu, 03 Jan 2002 14:49:05 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message