cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: some aggregation questions
Date Wed, 09 May 2001 10:08:35 GMT
Quoting Sylvain Wallez <sylvain.wallez@anyware-tech.com>:

> 
> 
> Giacomo Pati a écrit :
> > 
> > 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).
> > 
> > > 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.
> > 
> 
> +1 for a) 
> - if you aggregate parts, it's likely that these parts will be reused
> somewhere else in the sitemap
> - I agree with Giacomo concerning the readability of the map:aggregate
> when you have complex pipelines.
> 
> But there's an issue here : the parts have to be declared as complete
> pipelines, i.e. include a serializer, which means they're potentially
> visible by the user if he knows their URL. There may be cases when
> access to part information should be allowed only to internal requests.
> How can we handle that ?

This is already solved :)

<map:pipeline internal-only="true">
 ...
</map:pipeline>

Every pipeline inside the internal-only pipeline is only accessible by 
aggregator parts or by the "transparent" xinclude facility.

Giacomo

> 
> > > If you can give some hints - maybe I can change it myself...
> > 
> > sitemap.xsl ContentAgregator.java
> > 
> > Giacomo
> > 
> -- 
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 
> 

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


Mime
View raw message