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