forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Koberg" <>
Subject RE: [RT] Is speed slow because we use the document() function for skinconf?
Date Fri, 24 Oct 2003 12:53:33 GMT
> In fact he fact is that we transform the menu, then the body, then
> aggregate them, and then transfrom again. We have never gotten to really
> rethink this in a more speedy manner.
> Cocoon should cache the menu transformation (never checked though), so
> we would really have two of them, one for the document and one for the
> full page. So to speed up things we sould not do any transformation of
> he document first, and then use only one stylesheet for the cached
> menu+raw-contents xml.

How can you cache the menu's transformation if it needs to show a different
focus for each page?

Why does it need to be a separate transformations and not simply an
xsl:include/import (see below) and go straight to the final rendering? Then
you would not need two separate parsings of the XML brought in through the
document(). And you don't need the 3rd transformation. I could see benefits
in transforming and caching the footer and possibly the banner (unless the
tabs are in the banner and they need to show top level focus).

> But before doing this I would like to see real trials about performance.
> If you or someone shows that there are substantial gains in doing things
> another way with Forrest, I'd be happy to put them in.

I could send you some XML and componentized XSL. It would require a
CatalogResolver or preferably a custom URIResolver (which I could also send
but would need to be modified because it uses a lsb Project object).

Iterate/recurse over the site.xml (which is also used as the primary xml
Source), create a folder for each folder node and a file for each page node.

By using a custom resolver for the xsl:include/imports you can have a
default set of XSL that the forrest project maintains. However, you can
first check a project's well known directory structure for XSLs and if so
use those to override the default, else go to the forrest default. Cache the
Templates objects so the check only occurs once. 

If a user wants to override one or more of the xsl:include/imports. They
simply take one of the defaults and modify it to their needs. I prefer
xsl:includes over xsl:imports mainly because it encourages a smaller
Templates object.

We have the concept of primary and common XSLs. Primaries define a general
page layout and include the common (resolved) XSLs.

For example:
- default.xsl
- homepage.xsl
- section_homepage.xsl
- one_columm.xsl
- print_friendly.xsl
- debug.xsl (a functional test report)
- search_results.xsl (xsl to xsl transformation that is used to dynamically
style search result)
- error.xsl (xsl to xsl transformation that is used to dynamically style an
error message)

The above a some primary XSLs. They xsl:include common ones like:
- structure (folder)
  |- banner.xsl
  |- footer.xsl
  |- head.xsl
  |- nav.xsl
  |- tabs.xsl
  |- global_definitions.xsl (a bunch or variables setup from params passed
in and are used throughout the transformation)
- components (these are triggered by attributes in the site.xml)
  |- indexer.xsl (creates a list of a folder's contents based on site.xml)
  |- metadata.xsl (shows metadata on the page)
  |- pager.xsl ( show a < prev 1234 next >)
  |- snailtrail.xsl (like breadcrumbs)
  |- toc.xsl
  |- util_nav.xsl (for things like a printer icon, sitemap link, glossary
link, etc)
- content (for handling different kinds of content)
  |- lsb.xsl
  |- xhtml1.xsl
  |- whatever...

In a client/user project copy over the xsls you want to change from the
default. This way you can manage multiple projects from one forrest
instance, possibly sitting at

What do you think?


> Things possible to speed up:
>   1 - give skinconf params as <param> and not via document()


>   2 - rethink the page processing chain


>   3 - use STX instead of Xalan SAX

I am not a big fan of stx as I like to jump around a lot, but it makes sense
with the current way forrest/cocoon works. 

View raw message