forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] Is speed slow because we use the document() function for skinconf?
Date Fri, 24 Oct 2003 13:07:18 GMT
Robert Koberg wrote:

>>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?

The krysalis-site skin uses the same menu and folds with javascript.

> 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?

AFAIK currently (some "historical" reasons do not stand anymore) the 
only real advantage is about being able to cache page parts (but we 
still have to control that it actually happens, and extend it to footer, 
header, etc).

> Then
> you would not need two separate parsings of the XML brought in through the
> document(). 

When I will make the params go in as <param> and not via the 
document(function), this thing wil resolve in any case.

>>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.

Wait, I was thinking about real gains using Cocoon, not changing the 
whole system. Our main problem is not Cocoon, but the processing 
stylesheets and steps.

> 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. 

Ok, Cocoon does this by using the ResourceExistsSelector. The Templates 
are pooled and reused. So it should be the same till here.

> 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.

Basically like the current skins, where we have a common/ part and each 
skin does this.

> 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...

Conceptually it's the same here, only that we include the templates in 
less files and include all of them. Do you think that making it more 
granular could speed processing? (less templates to check-override)

But IMHO it's not here that we loose points...

> In a client/user project copy over the xsls you want to change from the
> default. 

ATM we are almost ready not to copy over anything.

> This way you can manage multiple projects from one forrest
> instance, possibly sitting at
>>Things possible to speed up:
>>  1 - give skinconf params as <param> and not via document()
> Sure.
>>  2 - rethink the page processing chain
> Definitely
>>  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. 

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message