cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: some aggregation questions
Date Tue, 08 May 2001 12:04:02 GMT
> Giacomo Pati wrote:
>
> Quoting Torsten Curdt <tcurdt@dff.st>:
> 
> > > > > There aren't any element inside a map:parm element:
> > > > >
> > > > >    <map:aggregate ...>
> > > > >      <map:part .../>
> > > > >      <map:part .../>
> > > > >    </map:aggregate>
> > > >
> > > > Yes... but I'd like to put elements there...
> > > >
> > > >     <map:aggregate ...>
> > > >       <map:part ... >
> > > >          <map:generate .../>
> > > >          <map:transform .../>
> > > >       </map:part>
> > > >       <map:part ... >
> > > >          <map:generate .../>
> > > >          <map:transform .../>
> > > >       </map:part>
> > > >       <map:transform .../>
> > > >       <map:serialize/>
> > > >     </map:aggregate>
> > >
> > > you can achieve the same results by putting each of the
> > generate/transform
> > > blocks in their own 'named' pipeline - but i agree, doing it this way
> > > would be handy sometimes. it doesn't break any seperation of concerns
> > that
> > > i can see, just an alternate syntax.
> 
> Ok, let's discuss this. The initial proposal was like the first 
> sample above 
> which nobody objected or came with another suggestion.
> 
> Now, after implementing that Torsten came up with another syntax (second 
> sample above).
> 
> So how should the <map:aggregate> snippet look like:
> 
> a) like the initial proposal
> b) like Torstens proposal
> c) a combination of both (ie. map:part must be empty if src attribute 
>    specified otherwise there should be generators/transformers inside 
>    map:part).
>
+10 for a)

I see three reasons for a):
1. We are going beta this week and we should avoid big changes right now.
   I personally have a list with others changes like that above, but we
   should really discuss them after version 2.0.
2. There was enough time to discuss the syntax of the aggregation.
3. I agree with Giacomo that defining separate pipelines and "only"
   aggregate them is the easier way for now. Otherwise we would really
   need all possibilities, like selectors, matchers and actions during
   the aggregation.

> > Hm, Giacomo, to you think this is hard to change? 
> 
> Well I don't think it should be that hard :)
> 
> > Putting everything
> > outside can be really anoying and is makeing the sitemap more complex
> > than it should be.
> 
> I don't agree here. I think it make sense to define separate 
> pipelines somewhere 
> in the sitemap and finally aggregate them into one single resource (ie. 
> debugging aspects).
> 
> Look, people will soon come with having actions, matcher and 
> selectors inside 
> map:part as well which doesn't make it look better. What would 
> you tell them 
> than? I feel it make more sense to have them separated. You see 
> each single 
> pipeline as it is and also see the aggregation how it is done as compact 
> snippets in the sitemap.
> 
> > If you can give some hints - maybe I can change it myself...
> 
> sitemap.xsl ContentAgregator.java
> 
> Giacomo
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

Carsten 

Open Source Group                        sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de                          mailto: cziegeler@sundn.de 
================================================================


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


Mime
View raw message