cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: Cocoon-view, Cocoon-sitemap documentation
Date Wed, 07 Nov 2001 07:44:31 GMT
On Wed, 7 Nov 2001, Stefano Mazzocchi wrote:

> Bernhard Huber wrote:
> >
> > Hi,
> > I don't mind having an attribute called label.
> >
> > The only objection I have I get confused if a
> > map:transform element has a label attribute.
> >
> > A map:label element helps me more visually to see
> > the point in the pipeline where the view takes its
> > xml content.
>
> really? well, you have both the starting and ending element, which one
> you choose is just a matter of personal perspectives anyway.
>
> I find a label much more readable and clear enough: but what do other
> think?
>
> I mean if I read something like
>
>  g
>  t1
>  t2
>  t3 - view1
>  t4
>  t5 - view2
>
> then I read it as
>
>  view1 = g -> t1 -> t2 -> t3
>
>  view2 = g -> t1 -> t2 -> t3 -> t4 -> t5
>
> but maybe it's just me.
>
> If we go
>
>  <view2>
>  <view1>
>   g
>   t1
>   t2
>   t3
>  </view1>
>   t4
>   t5
>  </view2>
>
> I see more confusion, not less. But I'm open to suggestions.
>
> > Having an attribute label I will be somehow unsure
> > wheter content of the view is taken
> > from before or after the transformation.
>
> well, both generators and transformers are "producers". A label means
> that you exit "after" the component has done it's job. Sounds simple to
> me.
>
> > But let's see for the different components:
> >
> > For generators it is absolutly clear, as there
> > is no xml prior to a generator the label means:
> > The content of the view is "after" the generator has been run.
>
> yes, but both have the same behavior from an XML producing point of
> view.
>
> > For transformers a label may mean before the transformation
> > or after the transformation.
>
> Yes, but it would make sense because that might conflict between a
> generator starting after and the transformer starting before, then
> duplicating the same information. The pipeline flow is fixed, so it's
> the label behavior. I think you get it after a couple of examples, and
> they you're done forever with it.
>
> > I think it makes more sense to define:
> > The content of the view is "after" the transformer has been run.
> > As the you may use a "generator" label to get the content
> > before the transformation step.
>
> Yep, exactly.
>
> > For map:aggregate a label has the same definition as for
> > map:transforms. Thus the definition is:
> > The content of the view is "after" the aggregation - being the
> > merge of all parts.
> >
> > For map:part of an map:aggregate the label means what?
>
> means that the view is created with the single part and the aggregation
> should be skipped. This is useful, for example, for our own
> documentation where the sitebar is aggregated but the "content" view
> should be just the document part.

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"/>
        </aggregate>
      </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?
On 2. either?

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

Giacomo

>
> > I am not sure if it makes sense to let map:part having an
> > attribute label.
> > I don't know.
>
> Even if Giacomo will have me for that (he's sitting right on my left
> trying to implement what I'm just typing) because the code is much
> harder, I think it does.
>
> > Thus for all elements so far it is always:
> > After the map:generate, map:transform, map:aggregate has run,
> > the content of this step is the content of the view defined
> > by the label attribute.
> >
> > The element map:serialize has no label attribute.
> > The element map:handle-errors has no label attribute,
> > but the components inside may have label attributes.
> > The element map:match, map:select, map:otherwise has no label attribute.
> >
> > So that's my suggestion regarding label attribute.
>
> Sounds great. When we are done with this, I volunteer to write a small
> doc about what views are for and how to achive them so people won't miss
> this "little treasure". Promise :)
>
> > Is it okay?
> > Are there any other sitemap elements I have forgotten?
>
> No, I don't think so.
>
>


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


Mime
View raw message