Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 4493 invoked by uid 500); 9 May 2001 08:11:33 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 4406 invoked from network); 9 May 2001 08:11:24 -0000 Message-ID: <3AF8FB5D.82B262FD@anyware-tech.com> Date: Wed, 09 May 2001 10:10:05 +0200 From: Sylvain Wallez Organization: Anyware Technologies X-Mailer: Mozilla 4.7 [fr] (WinNT; I) X-Accept-Language: fr,en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: some aggregation questions References: <989321213.3af7d7fd8f863@mail.otego.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Giacomo Pati a �crit : > > Quoting Torsten Curdt : > > > > > > There aren't any element inside a map:parm element: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes... but I'd like to put elements there... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 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 ? > > 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