You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/04/03 16:10:28 UTC

Re: map:aggregate and views : what's the correct behaviour ?

Sylvain Wallez wrote:
> 
> Hi team,
> 
> I just fixed a bug in the treeprocessor which was not handling views in
> map:aggregate like the compiled engine (see
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7196). However, this
> made me wonder about what should be the correct behaviour.
> 
> Let's consider the sitemap snippet that revealed the bug (from the docs
> sitemap) :
> 
>   <map:view name="content" from-label="content">
>    <map:serialize type="xml"/>
>   </map:view>
>   ...
>    <map:match pattern="*.html">
>     <map:aggregate element="site">
>      <map:part src="cocoon:/book-{1}.xml"/>
>      <map:part src="cocoon:/body-{1}.xml" label="content"/>
>     </map:aggregate>
>     <map:transform src="stylesheets/site2xhtml.xsl">
> 
> The label="content" on the 2nd part is used to select parts depending on
> the view. Both implementations do that equally well, that is, when
> requesting view "content", only "body-{1}.xml" is included.
> 
> The difference was about whether a part label should imply or not a jump
> to the view :
> - the compiled engine automatically jumps to the view as soon as one
> map:part has a corresponding label even if the map:aggregate doesn't
> have this label.
> - before fixing the bug, the interpreted engine jumped to the view
> _only_ if the map:aggregate also had a corresponding label (i.e.
> label="content" in the above snippet).
> 
> My opinion is that there are some uses case where automatic jump isn't
> good. Let's consider the following :
>   <map:view name="books" from-label="books">
>   ...
>   <map:aggregate element="root">
>     <map:part src="isbn-codes.xml" label="books"/>
>     <map:part src="authors.xml"/>
>   <map:aggregate>
>   <map:transform src="isbn2books.xsl" label="books"/>
>   <map:transform src="books2html.xsl"/>
>   <map:serialize/>
> 
> The "books" view should give the list of books. With automatic jump, the
> above only gives a list of isbn codes and we cannot apply
> "isbn2books.xsl". On the contrary, explicit labels mean that there's no
> jump to the view from map:aggregate and that the stylesheet is correctly
> applied.
> 
> So, in short, my opinion is that labels of map:part should be for
> _selecting_ which parts belong to the view, and that view branching
> should depend _only_ on the labels of map:aggregate.
> 
> What is your opinion ?

My opinion is that:

 1) the 'exit from last label' fixes your concern in the above example,
so no need to futher question this.

 2) both <map:aggregate> and <map:part> can have labels

Here are examples of use

1) part has label:

 <aggregate>
  <part ... label="content"/>
  <part .../>
 </aggregate>

the result is the output of the part, without any further processing
(the aggregator becomes transparent)

2) both part and aggregate has label

 <aggregate label="content">
  <part ... label="content"/>
  <part .../>
 </aggregate>

the result is the output of the aggregator, the internal label is
overruled.

3) more than one part has the same label

 <aggregate>
  <part ... label="content"/>
  <part ... label="content"/>
  <part .../>
 </aggregate>

this should be implemented by having the aggregator perform the
aggregation of the views that contain the requested label (the other
parts are ignored).

I don't think this is the current behavior, but this is how I picture
that aggregation should work with views.

Hope this clarifies things out.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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