cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernhard Huber" <bh22...@i-one.at>
Subject Re: Cocoon-view, Cocoon-sitemap documentation
Date Wed, 07 Nov 2001 19:36:36 GMT
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">

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


> 
> 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?)
Anyway let's assume it is a hidden listed component having 
label "content" by default.
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.

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.

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.

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.

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 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.
Another BTW, what's the difference between:
Many pipelines having only one only one match each,
and one pipeline having all matches? 
Just organisatorically?

bye, berni



Mime
View raw message