Well, for posterity, here's what I did:
No need to mess with the Generators; after much code grepping I went with
the following pipeline:
<map:match pattern="**/*">
<map:generate type="velocity" src="site.area">
<map:parameter name="path" value="{1}"/>
<map:parameter name="file" value="{2}"/>
</map:generate>
<map:transform type="cinclude"/>
<map:serialize type="html"/>
</map:match>
This copes with most requests.
Specifics are handled before this. (including pattern="**/" etc
The site.area Velocity template generates XHTML with <cinclude:include/>
tags with a src that can include velocity variables; eg:
<cinc:include src="cocoon:/vm/menu.vm?area=$path&page=1"
element="span"/>
(notice the & as query parameter separator)
or
<cinc:include src="cocoon:/xslt/document.html?page=3" element="span"/>
The XML is then cinclude processed to add menus and other 'components' (this
caches the body XML/XSLT transforms etc).
In the Velocity I used:
#set($file = $parameters.getParameter("file", "no file"))
to get the parameter passed from the sitemap.xmap and
#foreach ($p in $request.getParameterNames())
$p=$request.getParameter("$p") <br/>
#end
to access the query parameters.
I noticed that the cincluded files request object is a copy of the main
request object extended with any extra parameters. This means cincluded
files can see any parts of the main query if it's not overwritten by the
cinclude src URI.
I wonder whether semantics like this should be explicitly stated to ensure
the impact of changes in the future can be assesed?
David Greaves
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 14 December 2001 18:03
> To: [EMAIL PROTECTED]
> Subject: RE: Help: VelocityAggregator + Component approach to pages
>
>
> Vadim wrote:
> > > What I'd like to do instead is take the XHTML output of a
> > pipeline and
> > > essentially #include it into an XHTML template.
> > > That means that the template provides an 'Interface' for
> > sub-components (a
> > > <td> cell :) and expects the component to return well formed XHTML
> > suitable
> > > for inclusion in a <td>. The component then performs whatever data
> > gathering
> > > is required and renders it to XHTML etc...
> > > I can now get multiple components written, tested and debugged in
> > isolation
> > > (as pipelines) before simply binding them into a template (well,
> > that's the
> > > theory!)
> > > The existing aggregate is too simplistic for that.
> >
> > Take a look at cinclude/xinclude transformers. They do
> > exactly this (and
> > may be more). Consult
> > http://xml.apache.org/cocoon/userdocs/transformers/transformer
> s.html for
> the usage info.
>
> OK, looks good...
>
> I'm using a sitemap that invokes a Velocity generator that
> puts <cinclude>
> tags into the XHTML then transforming via cinlude and it
> works quite well.
>
> But (there's always one! :)
>
> I want to pass parameters to the pipelines I'm cincluding.
> If i <cinclude:include src="cocoon:/vm/menu.vm?area=/about">
> I'd like to get
> the menu for the /about area (the bean in the velocity
> pipeline page knows
> what I mean)
> However the cocoon:/vm/menu.vm doesn't seem to be able to access the
> "area=/about" parameter.
> Certainly it still accesses the main 'RequestWrapper' object
> (good, at least
> I can see that) is there a similar object that has the
> parameters for the
> Source cocoon:... URI?
> (In which case could/should the VelocityGenerator detect it's invoked
> 'internally' and pass an appropriate something wapper?)
>
> I think maybe cocoon.components.source.SiteMapSource builds something
> suitable (this.uri)?
>
> David
> PS Archives don't say much about cinclude
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
