cocoon-dev mailing list archives

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

Well, my proposal was of course c)! ;) Both should be possible!

I think my proposal is quite straight forward
- from a user's point of view. As long as nesting
makes sense it will be not comprehensible to the
user why not to nest the desired tags.
And I think this approach is right - as long it
doesn't break anything in terms of SOC.

And in this case it doesn't IMHO.

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

I personally think only having the current syntax works against
the sitemap concept. (Sorry, I haven't spoken up before the
implementation. Don't get me wrong!! I'm very(!!) happy to have
what we have right now ;) ) But now working with this stuff
I get more and more sitemap entries even for a single page.

I guess having these matchers that are only used internally
mess things up.

I encounter this when trying to pass a parameter from
the aggregation matcher to part matcher.


   <map:match pattern="included">
         <map:generate type="serverpages" src="included.xsp">
            <parameter name="path" value="{from_the_last_matcher}"/>
         </map:generate>
         <map:serialize/>
   </map:match>

   <map:match pattern="**/test.html">
    <map:aggregate element="page" ns="">
     <map:part src="included" .../>
     <map:part src=... />
    </map:aggregate>
   </map:match>

And even if this might be possible
by using {../1} (is it?) this is not very
nice IMHO because "included" makes only sense
together with the other matcher.

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

I think it is nothing bad to have actions and stuff inside... Why not?
Maybe again the flexibility syndrom... but I'm a friend of reusing
syntax as much as possible.

> > If you can give some hints - maybe I can change it myself...
>
> sitemap.xsl ContentAgregator.java

I gonna have a look at that ;)
--
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