Well, if you also have various parameters you want to use, I would use xsp
to create the url, but that's just my way:

<?xml version="1.0"?>
<xsp:page xmlns:xsp="http://apache.org/xsp";
  xmlns:xi="http://www.w3.org/2001/XInclude"; >
 <Document>
    <xsp:logic>
        String requestString = request.getParameter("firstrequestparameter")
+ request.getParameter("second") +.....;

    <xi:include>
   <xsp:attribute
name="href">cocoon:/<xsp:expr>parameters.getParameter("page-uri","")</xsp:ex
pr>?<xsp:expr>requestString</xsp:expr>#xpointer(/root/*)</xsp:attribute>
  </xi:include>
    </xsp:logic>
 </Document>
</xsp:page>

request.getParameter("") should get the request parameters while
parameters.getParameter("name","default") gets a sitemap parameter. inside
the logic you can do what you like, its just java! The #xpointer(/root/*)
does the same as the aggregation attribute 'element' set the xpath
expression you need (here select every child of root to include here, but do
not include the root element itself)

Use this in your sitemap:
    <map:generate type="serverpages" src="AggregatedPage.xsp">
            <map:parameter name="page-uri" value="{page-uri}"/>
   </map:generate>
   <map:transform type="xinclude"/>
    ....

This is just one way to do this, there are other ways!

Bye,

Jan

----- Original Message ----- 
From: "Jorg Heymans" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 19, 2004 3:06 PM
Subject: Re: slow pipeline (svg, aggregation)


> Hi Jan,
>
> I haven't really used cinclude or xinclude before.
>
> Here is my usecase : I need to iterate over all request parameters
> (unknown in advance how many there are or if there are any at all) and
> use them in my stylesheet that transforms the SVG.
>
> Can I use xinclude for this? I'ld be happy to because aggregation has
> proven to be very buggy (both in 2.0 and 2.1). I'm using 2.0.4.
>
> Thanks
> Jorg
>
> Jan Hoskens wrote:
> > I also used an aggregation to create my pages, until marc pointed me out
> > that you can do the same with xinclude. When I changed to xinclude
(passing
> > the URI as a variable) I had the impression that it all went just a
little
> > faster (Or was I just thinking slower;-). Maybe it's worth a try, it's
easy
> > to set up and may give a better result. (just one page, pass your uri
and
> > use the xinclude transformer)
> >
> > Cheers,
> >
> > Jan
> >
> > ----- Original Message ----- 
> > From: "Jorg Heymans" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, January 19, 2004 2:22 PM
> > Subject: slow pipeline (svg, aggregation)
> >
> >
> >
> >>You can tell my problem from this line in the access log:
> >>
> >>INFO    (2004-01-19) 14:00.15:336   [access] (/my.svg)
> >>http8080-Processor8/CocoonServlet: 'my.svg' Processed by Apache Cocoon
> >>2.0.4 in 3.6660166 minutes.
> >>
> >>So one SVG takes about 3.5 minutes to render. Now if i was rendering the
> >>surface of mars in svg i'ld be happy with this response time. For a 100k
> >>svg file i'm not. On faster machine i get like 50-150 seconds, depends
> >>(on what?)
> >>
> >>
> >>Sitemap.log reveals the delay starts with the contentaggregator
> >>
> >>DEBUG   (2004-01-19) 13:56.35:405   [sitemap] (my.svg)
> >>http8080-Processor8/ContentAggregator: ContentAggregator: generating
> >>aggregated content
> >>DEBUG   (2004-01-19) 14:00.13:763   [sitemap] (my.svg)
> >>http8080-Processor8/ResourceLimitingPool: Put a
> >>mypackage.CachingRequestGenerator back into the pool.
> >>
> >>Core.log points to the JaxpParser
> >>
> >>DEBUG   (2004-01-19) 13:56.35:406   [core.manager]
> >>(/app/cod/12L0101GE/render/heart_ginko_22_132x176.svg)
> >>http8080-Processor8/ResourceLimitingPool: Got a
> >>org.apache.avalon.excalibur.xml.JaxpParser from the pool.
> >>DEBUG   (2004-01-19) 14:00.13:739   [core.manager] (my.svg)
> >>http8080-Processor8/ResourceLimitingPool: Put a
> >>org.apache.avalon.excalibur.xml.JaxpParser back into the pool.
> >>
> >>My pipeline is an aggregated one
> >>
> >><map:match pattern="*/render/*.svg">
> >>  <map:aggregate element="aggregation">
> >><map:part src="file://{1}/{2}.svg"/>
> >><!-- we need this part because of the aggregator caching bug -->
> >><map:part
> >>
> >
> >
src="cocoon:/aggregate/{2}.svg?p1={request-param:param01}&amp;p2={request-pa
> >
ram:param02}&amp;p3={request-param:param03}&amp;p4={request-param:param04}&a
> >
mp;p2={request-param:param05}&amp;p2={request-param:param05}&amp;p6={request
>
> -param:param06}&amp;p7={request-param:param07}&amp;p8={request-param:param
08
> > }&amp;p9={request-param:param09}&amp;p10={request-param:param10}"/>
> >
> >>  </map:aggregate>
> >>  <map:transform src="stylesheets/make_svg.xsl"/>
> >>  <map:serialize type="svg2png"/>
> >></map:match>
> >>
> >><map:match pattern="aggregate/*.svg">
> >>  <map:generate type="cachingrequest"/>
> >>  <map:serialize type="xml"/>
> >></map:match>
> >>
> >>
> >>Thoughts?
> >>Jorg
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to