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 Tue, 06 Nov 2001 17:08:04 GMT
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.

Having an attribute label I will be somehow unsure 
wheter content of the view is taken
from before or after the transformation.

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.

For transformers a label may mean before the transformation
or after the transformation.
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.

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?
I am not sure if it makes sense to let map:part having an
attribute label.
I don't know.

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.
Is it okay?
Are there any other sitemap elements I have forgotten?

bye bernhard


----- Originalnachricht -----
Von: Stefano Mazzocchi <stefano@apache.org>
Datum: Dienstag, November 6, 2001 11:01 am
Betreff: Re: Cocoon-view, Cocoon-sitemap documentation

> giacomo wrote:
> 
> > I've talked to Stefano (he is my guest for some days here) about the
> > map:label stuff and we found that the approach was wrong. It 
> should be
> > an attribute.
> 
> Let me give you more details about why I think an element is wrong.
> 
> A "label" indicates the exit point that is matched by the view 
> handler.
> For example (again from the cocoon site sitemap):
> 
>   <map:generator  
>     name="file"        
>     src="org.apache.cocoon.generation.FileGenerator" 
>     label="content"
>   />
> 
> the file generator is implicitly given the label "content".
> 
>  <map:view name="content" from-label="content">
>   <map:serialize type="xml"/>
>  </map:view>
> 
> This "view" connects to the label "content". It means that if you ask
> for the "content" view of a resource, the pipeline will stop the 
> regularprocessing as soon as it encounters a "content" label, 
> either implicit
> or explicit. Then continue the processing defined in the 
> <map:view> tag
> (which normally includes some transformers and a serializer).
> 
>   <map:match pattern="...">
>    <map:aggregate ...>
>     <map:part src="..."/>
>     <map:part src="..."/>
>    </map:aggregate>
>    <map:transform .../>
>    <map:transform .../>
>    <map:serialize .../>
>   </map:match>
> 
> there are cases where the "content" is generated out of aggregating
> (say, on a news page) and other cases where the content is simply 
> one of
> the aggregated parts (like in the case where you aggregate a document
> with the sitebar).
> 
> In all cases, a label (either implicitly defined in the component
> declaration) must be matched to exit the regular pipeline and go 
> to the
> "view" one that terminates the processing on that resource for that
> particular view.
> 
> So, I believe it's much easier to say understand something like
> 
>   <map:match pattern="...">
>    <map:aggregate ... label="content">
>     <map:part src="..."/>
>     <map:part src="..."/>
>    </map:aggregate>
>    ...
>   </map:match>
> 
> than it is for
> 
>   <map:match pattern="...">
>    <map:label name="content">
>     <map:aggregate ...>
>      <map:part src="..."/>
>      <map:part src="..."/>
>     </map:aggregate>
>    </map:label>
>    ...
>   </map:match>
> 
> or even worse compare this
> 
>   <map:match pattern="...">
>    <map:label name="label1">
>     <map:generator.../>
>     <map:label name="label2">
>      <map:transform .../>
>      <map:label name="label3">
>       <map:transform .../>
>      </map:label>
>     </map:label>
>    </map:label>
>    <map:serialize .../>
>   </map:match>
> 
> with this
> 
>   <map:match pattern="...">
>    <map:generator... label="label1"/>
>    <map:transform ... label="label2"/>
>    <map:transform ... label="label3"/>
>    <map:serialize .../>
>   </map:match>
> 
> which provide the "exact" same information.
> 
> Now, I don't see any drawback in this approach, but if you see any 
> it'sthe best time to tell since views will place an vital role in 
> the future
> of Cocoon we must do out best effort to make it a very solid contract
> with our users.
> 
> If we choose to go the attribute way (and hopefully we do), there are
> two options:
> 
> 1) use the undefined namespace
> 2) use the sitemap namespace
> 
> so, either
> 
> <map:generator ... label="..."/>
> 
> or
> 
> <map:generator ... map:label="..."/>
> 
> but since we never used the sitemap namespace for attributes, I'd
> suggest 1)
> 
> What do you think?
> 
> -- 
> 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