cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Sitemap versionning in TreeProcessor?
Date Fri, 16 Jul 2004 08:29:29 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>>Carsten Ziegeler wrote:
>>>Sylvain Wallez wrote:
>>>>I noticed you added support for sitemap language versionning in the 
>>>>TreeProcessor a few weeks ago. What's the purpose of this?
>>>Actually, it's a feature we wanted to use for 2.1 already... A long 
>>>time ago, we agreed that if we change the sitemap syntax, we will 
>>>change the version number of the sitemap namespace.
>>Mmh... don't remember of the exact result of the discussion, 
>>but the fact is that the sitemap language has evolved 
>>incrementally (e.g. 
>><map:flow> <map:pipes> etc) in a backwards compatible way, 
>>and because of this backward compatibility, we didn't felt 
>>the need to change the namespace as sitemap for old versions 
>>would run with newer versions.
>Not exactly :) As far as I remember, we wanted to change the version number
>of the sitemap, *because* a 2.0 sitemap does not run without modifications
>in 2.1.

Well, it would have been easy for us to allow it, simply by defining 
builtin default values for <map:pipes>. I can't remember of any other 
needed modifications.

>But let's not argue about that :)
>Personally, I think, if we add new features, let's increase the version
>number. I think this is the usual way: if we make a new Cocoon release
>with new features, of course we increase the version number of Cocoon.
>So increasing the version number of the sitemap with new features
>seems natural to me.
>And of course Cocoon (or the TreeProcessor) is able to run the old
>version as well.

Okay. So we should decide on how the versioning is to be defined. Should 
it be a new namespace URI or an @version attribute as in XSL?

I like @version more, but the namespace URI already contains a version 

>>Ok, I understand and totally agree with your concerns with 
>>transparent configuration for the user.
>>Let me explain the current state of the refactoring, that led 
>>me to this question.
>>First, the purpose of this refactoring is to move from 
>>Composable to Serviceable, but also and more importantly to 
>>reduce to their bare minimum the dependencies on particular 
>>implementations on the container, so that it is easier to switch.
>>First step (Composable -> Serviceable) is done and committed 
>>Second step that is done on my HD is to remove the need for a 
>>special per-sitemap rolemanager for the contents of 
>><map:components>. This is done by simply moving these roles 
>>declaration in cocoon.roles. This therefore removes the need 
>>for the <roles> node in the treeprocessor configuration file.
>Great! So we have the behaviour back we had with our XSLT sitemap implementation :)

XSLT? Do you mean the compiled sitemap engine or Unico's version that 
flattens the tree?

>>The third step, which is underway and the most important 
>>change design-wise (but not that much code) is to decouple 
>>TreeProcessor and TreeBuilder. Currently, TreeProcessor loads 
>>sitemap-language.xml and gives it to a instance of 
>>TreeBuilder it itselfs creates.
>>This is a mixing of concerns, as the TreeProcessor should 
>>only be responsible for finding in which language the sitemap 
>>file is written, and lookup the appropriate TreeBuilder for 
>>that language. Loading sitemap-language.xml is the 
>>TreeBuilder's responsibility.
>Yepp - I thought this as well when I added the versioning.

Good. We're on the same thought line.

>>To achieve this, the system must be able to hold several 
>>implementations of TreeBuilder, whose difference can be 
>>limited to simply using a different configuration file (e.g. 
>>sitemap-1.1-language.xml). In order for this to be totally 
>>transparent to the user and avoid introducing a selector, I 
>>added a new entry in cocoon.roles named 
>>whose default class it o.a.c.c.treeprocessor.sitemap.SitemapLanguage.
>>To implement a new version of the sitemap language, we then 
>>just need to create a new TreeBuilder implementation (as 
>>simple as a subclassing SitemapLanguage to point to another 
>>config file) and the corresponding entry in cocoon.roles. 
>>Plus of course some logic in TreeProcessor to determine the 
>>actual TreeBuilder role that should be used.
>>How does it sound?
>Great! +1

Ok. So I'll continue that way, which means removing your configuration 
merging stuff in favor of separate config files. Note that the size of 
these files has been largely reduced since they no more contain role 


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message