cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <>
Subject RE: Views and RE: [VOTE] Retuning Sitemap Implementation
Date Mon, 14 Jan 2002 13:32:32 GMT
> From: Sylvain Wallez []
> Vadim Gritsenko wrote:
> >>>>3. Token expansion is allowed for all attributes.
> >
> > Done; yet there is an issue with the views, labels, and
> > map:generate|serialize|transform's type attribute. The issue is how
> > determine label of the particular component if at compilation time
> > of the component is not known (because of substitution).
> Sorry to jump in lately (I have hard times to follow the list), but
> not sure it desirable to allow substitution in component types and
> labels.

I tend to agree with you... btw, labels are not substituted - because
(in part) that they are allowed in <map:components> (where no
substitution possible).

> This could lead to very obscure sitemaps (refer also to "dynamic
> sitemap" Stefano is strongly against), and since source/parameters for
> sitemap statements often are component-specific, I don't see any real
> functional use for this.

One could come up with the example of usage; but I also do not think
that this functionality is required.

> > Thinking about views, why it is necessary to declare views and
> > component's labels in every sub-sitemap? If first is just
> > second poses more serious treat: every sub sitemap dealing with
> > must define own pool of components (read: use (sometimes: lots of)
> > memory), leading to scalability issues. I think there is need to
come up
> > with the mechanism to lookup view labels on run-time. Any ideas?
> This could be achieved by a using a specialized ComponentSelector that
> holds the labels for each component. But this means the sitemap is no
> more self-contained (views behaviour can depend on the parent
> > And I have another view-related question: what should be the correct
> > view behavior for the following sitemap fragment:
> >
> > <map:generators default="file">
> >   <map:generator type="file" src="..." label="content"/>
> > <map:generators>
> > ...
> > <map:generate src="data"/>
> > <map:transform src="data2page" label="content"/>
> > <map:serialize/>
> >
> > Now it seems invokes view right after generator.
> Jumping to a view occurs at the first statement having the label the
> view refers to, i.e. the generator in this case.

Shouldn't it be called after transformer? Or, if I want it to be after
transformer, I have to do something like this:

<map:generators default="file">
 <map:generator  name="file" src="...FileGenerator" label="content"/>
 <map:generator  name="file-nolabel" src="...FileGenerator"/>

<map:match pattern="body-changes.xml">
  <map:generate type="file-nolabel" src="xdocs/changes.xml"/>
  <map:transform src="stylesheets/changes2document.xsl"
  <map:transform src="stylesheets/document2html.xsl"/>

And this solution leads to issue #1: scalability problems. I'm just
imagining something like (thousands of users) on one
instance of Cocoon 2. It's a waste to allow every user have own pools;
and every user should have an ability to declare own labels. This leads
me to opinion that concerns are overlapping. Shouldn't it be possible to
declare labels without declaration of new components?

What do you think?


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

View raw message