On Thu, 8 Nov 2001, Bernhard Huber wrote:
Okay, lets make it clean:
A label on a generator or transformer is respected AFTER the component
has generated its SAX events. If there is a match between a requested
view and the label value (implicitely or explicitely defined) then
pipeline component selection is take from the view body instead
continuing sequentially within the sitemap.
A label on a <aggregate> element processes all part elements (anyway)
before braching to the view if the requested view matches the label
value. Take into account that if the src attribute of the part element
uses the cocoon:/ protocol those refered pipelines can be influenced by
a view request as well. i.e.
<view name="vv" from-label="v1">
<transform src="vv.xsl"/>
<serializer/>
</view>
...
<match pattern="foo">
<aggregate label="v1">
<part src="cocoon:/foobar"/>
<part src="foo.xml"/>
</aggregate>
<transform src="baz.xsl"/>
<serialize/>
</match>
<match patter="foobar">
<generate src="foobar.xml" label="v1"/>
<transform src="foobar.xsl"/>
<serialize/>
</match>
here a request of foo?cocoon-view=v1 will have:
generator(foobar.xml) + generator(foo.xml)
-> transform(vv.xsl)
whereas a request of foo or foo?cocoon-view=anyotherbutv1 will have:
( generator(foobar.xml) -> transform(foobar.xsl)
+ generator(foo.xml) ) -> transformer(baz.xsl)
A label on a part element of an aggregation will result in a selection
of the part only if there is a part that satisfies a view request or all
if no possibly attached label to a part matches the requested view (if
any was requested).
Hope this makes it clearer.
Giacomo
> Hi,
> 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.
>
> Okay
>
>
> >
> > 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:
> <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="v2"/>
> <part src="cocoon:/bar" label="v1"/>
> </match>
> </pipeline>
> <pipelines>
>
> 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.
>
>
> >
> >
> >>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.
> >
>
> 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
> labels.
>
>
> >
> >>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">
> > <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-
> >>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 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
> example).
> 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
> implementing.
>
> 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
> sitemap.
> Top-level matches like the foobar. Next second-level matches like bar,
> and foo. More fine grainded matches, moreover resources, and internal
> pipelines.
> 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
> >>matching,
> >>first match in the pipeline hierachy.
> >>
> >
> > Aggreed.
> >
> >>
> >
> > This will come in a newer approach to pipeline assemly specification
> > (the flowmap/urimap/pipeline spec.)
>
> okay
>
>
> >
> >
> >>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..
>
> berni
>
>
> >
> > Giacomo
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
> >
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
