cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Substractive view labels [was : Re: aggregate and views : what'sthecorrect behaviour ?]
Date Tue, 26 Mar 2002 13:43:46 GMT
Sylvain Wallez wrote:

> Attaching a label to a component (e.g. a generator) makes this label
> implicit for _all_ uses of that component. This is useful when the kind
> of information represented by the label is always produced by that
> component, since this avoids adding this label everywhere in the
> pipeline where this component is used.
> In Cocoon's documentation sitemap, the "content" label is associated to
> the document DTD, and this is _most often_ produced from files, hence
> the label "content" on the "file" generator. Now this is only _most
> often_ and not _always_ : todo.xml, faq.xml, changes.xml aren't in the
> document DTD and need an initial transformation, and only after this
> transformation can they can have the "content" label, as in the
> following extract from the doc sitemap :
>    <map:match pattern="body-todo.xml">
>      <map:generate type="file-nolabel" src="xdocs/todo.xml"/>
>      <map:transform src="stylesheets/todo2document.xsl" label="content"/>
>      <map:transform src="stylesheets/document2html.xsl"/>
>      <map:serialize/>
>    </map:match>
> Since "file" generator has a "content" label, it cannot be used here,
> otherwise "todo2document.xsl" isn't applied when the view is requested.
> So a solution was to define a new "file-nolabel" generator, which has
> the *exact same definition* as the "file" generator but doesn't have the
> label.
> The problem with this approach is that only 3 files in the whole docs
> have this special requirement of an initial transformation, and this
> requires to create a new component and all the associated overhead :
> duplicate configuration, duplicate handler in the component selector and
> duplicate object pool. As Vadim pointed out, do that in a shared Cocoon
> installation where every user can have its sitemap and you can buy some
> more RAM !
> So my proposal was to allow to locally "substract" a label defined at
> the component level. The above snippet would then become :
>    <map:match pattern="body-todo.xml">
>      <map:generate type="file" src="xdocs/todo.xml" label="-content"/>
>      <map:transform src="stylesheets/todo2document.xsl" label="content"/>
>      <map:transform src="stylesheets/document2html.xsl"/>
>      <map:serialize/>
>    </map:match>
> This avoids the overhead of declaring a new generator and clearly shows
> that we have a local modification of the label globally attached to the
> "file" generator.
> Is it more clear ? And if yes, what do you think ?

Ok, perfectly clear.

Now, please, tell me: why is the other solution we proposed to this
problem (that is: exit on the 'last' conten view, not the first one)
wasn't accepted. I still think it's the most elegant solution.

Sure it is harder to implement, but we never did designed forced by
implementation difficulties and I don't see why we should start now.

> And please don't forget my other post about views in aggregation :)

Sorry, I thought that was sorted out: what's the problem again (I think
I missed it previously).

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message