cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Cocoon-view, Cocoon-sitemap documentation
Date Wed, 07 Nov 2001 00:18:22 GMT
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.

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

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Mime
View raw message