cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Substractive view labels (long)
Date Tue, 26 Mar 2002 17:45:40 GMT
Stefano Mazzocchi wrote:

>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
>>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.
Let me put back the explanations I gave to Volker Schmitt, with some 
more details. The below sitemap will be used for these details 
(high-level structural elements skipped for simplicity) :

<map:view name="content" from-label="content">
  <map:transform src="content2html.xsl"/>

<map:resource name="foo">
  <map:transform src="foo.xsl" label="content"/>

<map:resource name="bar">
  <map:act type="updatedatabase"/>
  <map:transform src="bar.xsl"/>

  <map:match pattern="foobar">
    <map:generate src="foobar.xml" label="content"/>
    <map:act type="findtype">
      <map:call resource="{type}"/>


 From a user point of view, knowing when branching will occur can become 
a nightmare since you have to crawl all branches that can participate in 
a request handling (matchers, selectors, actions, resource calls, etc) 
in search for this last label.

In the above sitemap, there's a "content" label on the generator, but 
the "foo" resource also has this label. If the last label is used, you 
cannot know by reading the "foobar" pipeline if the view will start at 
the <map:generate> or not. You have to examine all possible branches 
(and in the above case, they're dynamic) to find other places where the 
same label is used.

Using the first label makes the behaviour more predictible : if a 
labelled statement in the sitemap is reached, then we *know* that the 
view starts at this statement.


Implementation will be difficult, as it requires the whole regular 
pipeline (the view-less one) to be built before deciding at which point 
should occur branching.

I agree that specs shouldn't be constrained by implementations details. 
However, we must be aware that this requires some big changes in the 
existing pipeline architecture to "break" the regular pipeline at a 
point. But the important point here is that we need to fully build the 
regular pipeline to know the branching point (see below).


Corollary to the previous point, building the regular pipeline may have 
some side effects (e.g. actions) _after_ the branching label, but we 
cannot know beforehand that these actions shouldn't have been executed 
because they're not in the view.

This is illustrated in the above sitemap : the "bar" resource has an 
action that modifies the system state, but since there is no "content" 
label in the "bar" resource, the view starts from the generator, that is 
*before* the action in the sitemap flow. Should this action be executed 
when the view is requested ?

This leads to an interesting question. In "retuning sitemap design" (see, 
you classify sitemap statements in two main categories : direct 
components (generators, transfomers, etc) and indirect components 
(matchers, selectors, actions, etc). How does view handling relate to 
this classification ?

In the current definition of views, there is no difference between 
direct and indirect components, and the sitemap is executed up to a 
matching label that causes a jump to the view. Components after the view 
label, both direct and indirect, aren't executed.

If we change the behaviour and branch from the last label, this means 
that *all* indirect components of the regular pipeline are to be 
executed because they perform the routing in the sitemap and there 
execution is therefore required to find the last label.

Is this really what we want ? My opinion is no : this would make 
understanding views and predict there behaviour really difficult. Views 
are a powerful concept and many users already have difficulties to 
master them. Turning them to black magic won't promote their use.


Conclusion (thanks for those who have read all of the above ;)

I consider the label-on-component feature a writing facility to avoid 
tedious repetition in the pipelines. The documentation sitemap (with 
"file" / "file-nolabel") clearly shows that views are attached to a 
particular DTD that exists at some places in the pipelines, and that 
attaching their labels to general-purpose components like the resource 
generator may not be a good thing : 80% of the uses of that generator 
produce the correct DTD, but we need to be able to handle the remaining 
20% without sacrificing the writing facility. That's why I suggested 
these "substractive labels" to avoid the declaration of a new component 
and the associated overhead.

Also, I didn't find in the archive the reasons for this "move to last 
label" todo. And I wouldn't be happy if this was proposed as a 
workaround for the label-on-component problem. We should not constrain 
the definition of views by the bad side-effects of a writing facility.


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

One-click reminder ;)


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

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

View raw message