cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Substractive view labels [was : Re: aggregate and views : what'sthe correct behaviour ?]
Date Sun, 24 Mar 2002 20:59:09 GMT
Stefano Mazzocchi wrote:

>Sylvain Wallez wrote:
>
>>This is about a todo that says "View must start not from the first
>>encountered label, but from the last one". Here's below Vadim's answer
>>to my request for enlightment about it :
>>
>> > Vadim wrote :
>> >> Sylvain wrote :
>>
>>>>Also I'm not sure this is a good thing (can be confusing) and it
>>>>would be difficult to implement.
>>>>
>>>Take a look at the documentation pipeline. Right know it requires hacks
>>>like this:
>>>------------8<--------------
>>> <map:generators default="file">
>>>  <map:generator  name="file"
>>>src="org.apache.cocoon.generation.FileGenerator" label="content"/>
>>>  <!-- FIXME: Change this once better view handling is implemented -->
>>>  <map:generator  name="file-nolabel"
>>>src="org.apache.cocoon.generation.FileGenerator"/>
>>> </map:generators>
>>>------------8<--------------
>>>
>>>Yes, it works for now but it is just a hack to overcome current views
>>>implementation.
>>>
>>>To defend my point even further... If you think about this in the
>>>context "one sitemap per user", "hosting environment", and take into
>>>account that every <map:generator/> line is actually a *pool*... You
>>>know, you will run out of resources before you finish reading this email
>>>;)
>>>
>>To solve this problem, I don't think jumping from the last label is the solution.
What is outlined above is that we need a way to "forget" labels defined on a component at
particular locations in the pipelines. So I'm thinking of an extension of the label attribute
syntax to be able to substract some or all of the labels defined at component level.
>>
>>Some examples :
>>- map:generate label="foo" adds label "foo" to labels defined on the component (current
behaviour),
>>- map:generate label="-, foo" puts only label "foo" on this statement,
>>- map:generate label="-content" will substract label "content" from those defined
on the component
>>- map:generate label="-" will remove all labels
>>
>>What is your opinion on this ?
>>
>
>Excuse my probable lack of focus at the moment (being at Giacomo's
>place), but I didn't get it.
>
>Can you please outline what is the problem you are trying to solve and
>why you need to 'subtract' view labels?
>

Ok. Vadim, correct me if I'm wrong !

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 ?

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

Sylvain

-- 
Sylvain Wallez
 Anyware Technologies                  Apache Cocoon
 http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message