cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: Cocoon-view, Cocoon-sitemap documentation
Date Wed, 07 Nov 2001 22:01:57 GMT
On Wed, 7 Nov 2001, Bernhard Huber wrote:

> Hi, giacomo
> I reconsidered the map:part labelling, too.
> > It's not that easy (semantically and of course implementational).
> > Imagine this:
> >
> >  <components>
> >    <generator name="a" ... label="content"/>
> >    <generator name="b" ... label="content"/>
> >  </components>
> >  ...
> >  <pipelines>
> >    <pipeline>
> >      <match pattern="foo">
> >        <generate type="a" label="v1"/>
> >        <serialize/>
> >      </match>
> >      <match pattern="bar">
> >        <generate type="b"/>
> >        <serialize/>
> >      </match>
> >      <match pattern="foobar">
> >        <aggregate>
> >          <part src="cocoon:/foo" label="v1"/>
> >          <part src="cocoon:/bar" label="v2"/>
> >
> >      </match>
> >    </pipeline>
> >  <pipelines>
> >
> > 1. request=foobar,view=content
> > 2. request=foobar,view=v1
> >
> > From a semantic point of view what did you get?
> >
> > On 1. wouldn't you expect the content from all parts?
> yes, i would expect to get the content of all, parts. Or saying
> in other words the xml content of the map:aggregate.
> I would not expect only the <generate type="b"> content, although
> it is referenced by the <part src="cocoon:/bar" label="v2">

Wrong (after thinking about it again). An aggregator is nothing you
implicitely can label like a generator. Thus, a content view would be
deliverable. Instead you'll have to label it explicitely like:

   <aggregate label="content">

Well, in the above snipped it would produce the content of both parts
because the underlying pipelines (in concrete their generators) are
implicitely labeled.

> On 2. either?
> I would expect xml content ONLY of <part src="cocoon:/bar" label="v2"/>

I see. I have not had my cups of coffee this morning. Now I see that
I've fucked up the sample I originally wanted to present :(/

If you exchange the label names on the map:parts above and request
"foobar"s view "v1" would you expect to get the v1 view from both parts
(becaue the cocoon:/foo pipeline is labeled "v1").

> > From implementation point of view it's much worse (at least with
> > XSLT to
> > generate the code out of the sitemap markup).
> >
> > On 1. how did the aggregator template know about its part being
> > references to pipelines which could produce a view?
> >
> Let's consider <map:aggregate>.
> It is not listed in the components. (Why?)

It is internally known by the sitemap engine (similay to the map:mount

> Anyway let's assume it is a hidden listed component having
> label "content" by default.

You cannot assume that because there are no standardized or implicit or
well-known labels yet. What will happen if you assume that but remove
the view definition for content?

> Okay.
> Moreover as it is the first producer in the pipeline it has the
> label "first" set.
> So you really have written <map:aggregate label="content,first">.
> Thus requesting foobar?cocoon-view=content, or foobar?cocoon-view=first
> will give me content of ALL parts.

You're assuming there are standard labels which is not. Also, the
multiple lables separated by comma syntax isn't implemented yet.

> The first part element in the <map:aggregat> it has explicitly set a
> label.
> Okay so requesting foobar?cocoon-view=v1 will give me xml content of
> part 1.
> Same argument for second map:part.
> Now talking more generally:
> What is the scope of a label?
> Can a producer pass its label upward?
> What is the precedence hierarchy of labels?
> Now I see this becomes more and more the dimension of a programming
> language.

Exactly the point I am getting into :/

> But let's rewrite your pipeline, expanding the cocoon: URIs, your
> sitemap regarding URI foobar is (expanded sitemap):
>       <match pattern="foobar">
>         <aggregate label="content,first">
>           <part label="v1">
>             <generate type="a" label="v1"/>
>           </part>
>           <part label="v2">
>             <generate type="b" label="content"/>
>           </part>
>         </aggregate>
>       </match>
> Thus again
> URI: foobar?cocoon-view=content -> xml content of aggregate, i.e. part-
> 1 + part-2
> URI: foobar?cocoon-view=v1 -> xml content of part-1, as part-1 has the
> label v1 set.
> URI: foobar?cocoon-view=v2 -> xml content of part-2, as part-2 has the
> label v1 set.

The way I wanted to write my example was:

       <match pattern="foobar">
           <part label="v2">
             <generate type="a" label="v1,content"/>
           <part label="v1">
             <generate type="b" label="content"/>

This would result in:

   foobar?cocoon-view=content -> content view of aggregate, i.e.
   part-1 + part-2 because all generator has a "content" label

   foobar?cocoon-view=v1 -> same, because the generator on part-1 as
   well as the 2. part have a v1 label.

   foobar?cocoon-view=v2 -> this would only produce the 1, parts view

> In this sitemap I would say, it is impossible to get the content of
> part-2 only, by
> specifying ?cocoon-view=content, you MUST say ?cocoon-view=v2.

Correct. You have to follow the sequence and this will produce something
on the 1. part first.

> Moreover I think the labelling mechanism now, will force the sitemap-
> designer
> to bundle all real-content into one part, and all other xml content
> like menu, advertisment, etc into other part.
> For the "all other" content is is not that bad to get some more
> specific view
> only be specifying some more specific label-name.
> But by the label spec today I think, that the sitemap-designer,
> has to consider unique label names for all content parts.

I've lost you here.

> I would say the labels are a simple mechanism. It is just simple string
> matching,
> first match in the pipeline hierachy.


> Thinking more complicate, or more general.
> Then I would say it possible to express a view by an XPATH expression,
> relative to
> start of the concrete pipeline processing.


> As the foobar matches, virtually a DOM tree of the complete pipeline
> processing is available, in the above example it the expanded sitemap.
> Now the view may specify some node, or leaf of this document, specifying
> excatly the content.
> Let's make some examples:
> foobar?cocoon-view=content -> xml content of aggregate
> foobar?cocoon-view=content/v1
> foobar?cocoon-view=**/v2
> In this concept you can get rid of the label, completly, just
> specifying normal
> xml ids.
> The bad thing it is more complicate for the sitemap-designer, the
> sitemap-programmer,
> and the sitemap-documentation writer. :)
> BTW, a pipeline should have a name anyway, thus it is easier to ref it.

This will come in a newer approach to pipeline assemly specification
(the flowmap/urimap/pipeline spec.)

> Another BTW, what's the difference between:
> Many pipelines having only one only one match each,
> and one pipeline having all matches?
> Just organisatorically?

the <handle-error> element.


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

View raw message