cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernhard Huber" <>
Subject Re: Cocoon-view, Cocoon-sitemap documentation
Date Thu, 08 Nov 2001 00:54:16 GMT
i will try to answer, testing if I understood your thoughts.
sorry, but my english is not that perfect.....

> 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">

Okay, aggregate is like a non-labelled generator component in that respect.

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


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

Okay having something like:
    <generator name="a" ... label="content"/>
    <generator name="b" ... label="content"/>
      <match pattern="foo">
        <generate type="a" label="v1"/>
      <match pattern="bar">
        <generate type="b"/>
      <match pattern="foobar">
          <part src="cocoon:/foo" label="v2"/>
          <part src="cocoon:/bar" label="v1"/>

Now requesting foobar?cocoon-view=v1, i would expect getting only part-2
as it has the label v1, but not part-1 as it has a different label.
And here i stop matching v1, ignoring the labels of the generators.
I think you have a different matching strategy in mind.
I just want to express my thoughts:
I think it is quite complicate to make in-depth search for any producer 
having set the requested label, not only implementing, but as a
sitemap designer you must learn this matching-strategy, and try to
apply it, in case you have to debug labels if you have some "unwanted" 
content in a view.

In this respect the label "v1" is hidden on level below the aggregate 
level. But you may think of more complicate examples where "foo" is
an aggregate, too, and a generator of the "foo" aggregator has set the 
requested view label.

Thus a sitemap-designer should make some rules how to organize the 
labels, more a bit later.

>>>>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 see if I can help, perhaps I'm wrong.
I think as the content flows in the pipes of cocoon, the content has
the xml which is the content. Moreover as the content has a bag for the 
labels, each generator, and transformer puts its label into this bag. 
Thus the label bag may only grow. After each producer step, there
happens a check: Does the request view name matches any label of the 
label-bag. If at least one label of the label bag matches there is a 
chance that content is alreay the content of the view. But to be sure
to finish to early, there should be some list of labels which we will 
expect further on. If the label is not found in this list we know that 
how much content will be generated from now on, it will be not part-of 
the content-view. Thus we may stop now generating content, and start to
do the view processing.
But before we can to that we may have to remove some content?
No, we don't remove any content!

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

Okay. Map:mount, and map:aggregate are no components like all 
generators, transformers, etc. Thus map:mount, and map:aggregate are not 
listed in the components section.
But they are powerful players regarding how a sitemap works, but hidden 
from the eyes of sitemap-designer. It's a pity for them perhaps they 
want to see some more light, becoming well known and highly respected :).

>>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?

What about the first, and last label? Regarding content view you are 
right. I was making some assumptions to make examples below more clear.

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

I was not assuming that the sitemap-designer types, multiple labels, but
that's what the sitemap-engine sees, as I was assuming there are default 

>>The first part element in the <map:aggregat> it has explicitly set a
>>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
> 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">
>          <aggregate>
>            <part label="v2">
>              <generate type="a" label="v1,content"/>
>            </part>
>            <part label="v1">
>              <generate type="b" label="content"/>
>            </part>
>          </aggregate>
>        </match>
> 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

I see.

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

I see.

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

I agree.

>>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-
>>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 think we have had different understandings about a label.
You prefer to implement: Go through all the producers which are enclosed 
by the matched map:match (or map:select/map:test/map:otherwise), 
including internal pipelines, and sub-matches (like pattern="foo" in our 
If such a producer has declared the requested label it content will be 
part of requested view,
otherwise not.

Is this right?

I have not had such go into-depth approach but a simple minded match 
only once, cut-off everything else not being part-of that match.
I think my idea is more restrictive, hence the talking about main 
content, and advertisment, and bundeling. Using my idea will fore
the sitemap-designer to use aggreate for merging content, and getting
all the same label that matches.

But anyway I think your idea is more flexible, and more easy to implement.

I'm just trying to find some way to use that view/label system you are

If I'm a sitemap-designer what will be a good practice to administer my 
labels in your system?

I will have a bag of labels, no wait first I have a hierarchy in may 
Top-level matches like the foobar. Next second-level matches like bar, 
and foo. More fine grainded matches, moreover resources, and internal 
Thus this hierarchy of content is merged/aggregated together in order to 
get the content delivered to the browser, user, ..
Now the view(s) specified by labels give me the possibility to pick only 
certain content.

Now how should I place the labels, in that hierarchy?
Okay first and last label are clear, as they are available and placed.

Having a label v1, depending on which producer will be labelled v1 it 
becomes part of the view v1.
Now a producer being labelled v1, is excluded from view v2, as each 
label attribute is allowed to contain only one label. (Perhaps it makes 
sense to allow the comma-separte label list, I don't know neither 
implementing nor using it). The exception of this rules is, if the 
producer is part-of an aggregate, directly or indirectly.

Or in other words if the parent of a generator is labelled v1, then all 
of its part-of children are part of the view v1, even if the children 
have no v1 label.

>>I would say the labels are a simple mechanism. It is just simple string
>>first match in the pipeline hierachy.
> Aggreed.
> 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.

Okay, thanks for that hint, I have overseen that.

Thanks for that interesting thread..


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

If I have seen further it is by standing upon
the shoulders of Giants.
-- Sir Isaac Newton

Huber Bernhard

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

View raw message