vfs branch?

[Jeff Turner <je...@apache.org>]

Hi,

I have a modified version of Forrest that doesn't need to copy
src/documentation/* files into a temporary context.  Files edited in
src/* are immediately visible in the webapp.

This works by abstracting the location of resources/* and skins/* files
with Cocoon pipelines.  Instead of using:

<map:transform src="resources/stylesheets/faq2document.xsl"/>

It uses:

<map:transform src="cocoon://resources/stylesheets/faq2document.xsl" />

Where the 'resources/stylesheets/**' pipeline serves content either from
the project resources/stylesheets/ directory, or otherwise from the
${forrest.home}/context/resources/stylesheets/ directory.

Same thing with skins.  We have:

<map:transform src="cocoon://skin/xslt/html/document2html.xsl">

And a skins.xmap pipeline works out which skin to use, and in which
directory.

So effectively, the sitemap first constructs a virtual filesystem of
content and resources, and then uses the virtual resources to render the
virtual content.  Like Cocoon blocks, only less vaporous ;)

Predictably, this is all dog slow.  Rendering time went from 7 mins to 10
mins 40s on my system.

So I would like to add my changes to a 'vfs' (virtual filesystem) branch
in CVS, where I (any anyone interested) can do some serious profiling and
optimizing, without disturbing everything else.

Or does anyone have other ideas on how we could dynamically select which
XSLT to apply, based on the presence or absence of a user-supplied file?


--Jeff

Re: vfs branch?

[Stefano Mazzocchi <st...@apache.org>]

Jeff Turner wrote:

> So effectively, the sitemap first constructs a virtual filesystem of
> content and resources, and then uses the virtual resources to render the
> virtual content.  Like Cocoon blocks, only less vaporous ;)

LOL :)

Touche'.

> Predictably, this is all dog slow.  Rendering time went from 7 mins to 10
> mins 40s on my system.
 >
> So I would like to add my changes to a 'vfs' (virtual filesystem) branch
> in CVS, where I (any anyone interested) can do some serious profiling and
> optimizing, without disturbing everything else.

go ahead.

> Or does anyone have other ideas on how we could dynamically select which
> XSLT to apply, based on the presence or absence of a user-supplied file?

I don't think it's possible.

the vaporous dynamic blocks of 2.2 will make this possible. ;-)

Stefano.