cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Views and RE: [VOTE] Retuning Sitemap Implementation
Date Tue, 15 Jan 2002 18:56:28 GMT
Sylvain Wallez wrote:

> > Done; yet there is an issue with the views, labels, and
> > map:generate|serialize|transform's type attribute. The issue is how to
> > determine label of the particular component if at compilation time name
> > of the component is not known (because of substitution).
> Sorry to jump in lately (I have hard times to follow the list), but I'm
> not sure it desirable to allow substitution in component types and view
> labels.
> 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.

Completely agreed. I forgot about that attribute.

In theory, that attribute should have been map:label to indicate that
has special semantics, but that would be back incompatible.

So, the option is to leave it as it is, but remove the ability to make
labels dynamic.

> > Thinking about views, why it is necessary to declare views and
> > component's labels in every sub-sitemap? If first is just inconvenience,
> > second poses more serious treat: every sub sitemap dealing with views
> > 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 sitemap).

I agree with Vadim here: you should be declaring something *only* when
you want to override the behavior inherited by the parent sitemap.

Self-containment is a strong requirement, but in this case this isn't
really a limitation: if you want to specify your special behavior (means
override the inherited behavior) you specify so, otherwise, you are
'self-consistently' stating that you are using your parent's one on that

Sure, this might break operation, but this is exactly the same if your
parent sitemap mapped a 'default' component on a different one and not
one that you were expecting.

> > 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.

It should be the *last* one, not the first one.

The above fragment is very useful and stopping at the first label is
plain useless since we are simply stating that the 'content' of that
pipeline is coming after the transformation, overriding the default.

If Vadim is right and current behavior reflects what Sylvain says, we
have a bug.

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