cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@dff.st>
Subject Re: AW: some aggregation questions
Date Tue, 08 May 2001 12:50:51 GMT
> > > > > > 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.

Well, that's totally reasonable...
+1

> 2. There was enough time to discuss the syntax of the aggregation.

But why not discussing it again if the current implementation
might be as flexible as it could/should be?

(Doesn't mean it should be high priority...)

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

Yep! I think we do ;)
--
Torsten


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


Mime
View raw message