Piotr, > Right?
Yes :) But don't serialize those parts as HTML, use the XML serializer instead. > Hm. I'm not sure about it. What happens when line > <map:part src="cocoon:/menu.xml"/> > is executed? Cocoon jumps directly to pipeline which matches the > pattern, makes something there (ie *map:read* (or should I use > map:generate?) source xml, *transform* using xsl, *serialize* (is this > neccessery here?)) and returns to second map:part. Well, pipelines are pipelines, the "cocoon:" pseudo-protocol is just another way to call them. > > So the joined parts are not xml files anymore but html files? Parts should be XML to be aggregated, just use the XML serializer. BTW, don't think of them as "files", but rather as "XML streams". > And when use separate <map:pipeline> for matches and when to group this > matches under one <map:pipeline>? I know it looks like completely > another question;-) > This has been answered over and over... check the mailing list archives or point your browser to: http://xml.apache.org/cocoon/faq/faq-sitemap.html#faq-9 Best regards, Luca Morandini [EMAIL PROTECTED] > -----Messaggio originale----- > Da: Piotr Legiecki [mailto:piotrlg@;sci.pam.szczecin.pl] > Inviato: giovedi 14 novembre 2002 14.36 > A: [EMAIL PROTECTED] > Oggetto: Re: R: Difference between cocoon: and file:// in map:part > > > Luca Morandini wrote: > > Piotr, > > > > the "cocoon:" pseudo-protocol doesn't search for files, but for > pipelines. > > > > With this pseudo-protocol you can build pipelines and call them (more or > > less as subroutines) from any aggregation. > > > > I see. So when I want to separate navigation and content (having > menu.xml and books.xml) and join them using aggregate, *but* use > different xsl files for them I can write something like this: > > <map:pipeline> > <map:match pattern=""> > <map:aggregate element="site"> > <map:part src="cocoon:/menu.xml"/> > <map:part src="cocoon:/books.xml"/> > </map:aggregate> > <map:transform src="styles/menuandbook2html.xsl"/> > <map:serialize/> > </map:match> > </map:pipeline> > > > <map:pipeline> > <map:match pattern="menu.xml"> > <map:read src="content/menu.xml"/> > <map:transform src="styles/menu.xsl"/> > <map:serialize/> > </map:match> > </map:pipeline> > > <map:pipeline> > <map:match pattern="books.xml"> > <map:read src="content/books.xml"/> > <map:transform src="styles/books.xsl"/> > <map:serialize/> > </map:match> > </map:pipeline> > > Right? Hm. I'm not sure about it. What happens when line > <map:part src="cocoon:/menu.xml"/> > is executed? Cocoon jumps directly to pipeline which matches the > pattern, makes something there (ie *map:read* (or should I use > map:generate?) source xml, *transform* using xsl, *serialize* (is this > neccessery here?)) and returns to second map:part. > > So the joined parts are not xml files anymore but html files? So I > can't use > <map:transform src="styles/menuandbook2html.xsl"/> > on them anymore and I can't also use > <map:serialize/> > > Is it the right way to use aggregate or I have simply missused > this feature? > > And when use separate <map:pipeline> for matches and when to group this > matches under one <map:pipeline>? I know it looks like completely > another question;-) > > Regards > Piotr Legiecki > > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> > We are protected from the virus by Norton Antivirus Corporate Edition --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
