cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Help: VelocityAggregator + Component approach to pages
Date Mon, 17 Dec 2001 13:29:18 GMT
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:transform type="cinclude"/>
	<map:serialize type="html"/>

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&amp;page=1"
  (notice the &amp; as query parameter separator)
  <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/>
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: []
> Sent: 14 December 2001 18:03
> To:
> 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
> >
> 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:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message