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 07:50:42 GMT
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.

>Now, we definitly will add new features for 2.2 (e.g. the virtual
>sitemap components), so we have to change the version number.
>I'm planning to implement the virtual sitemap components in the next
>weeks, so we need it then :)

Again, I don't think changing the namespace URI is a good idea.

>>And if this is really needed, considering that it's not 
>>likely to happen often, 
>It *might* happen with every minor or major version change.
>>it seems to me simpler to have 
>>different configurations files (i.e. 
>>"sitemap-language-10.xml", "sitemap-language-11.xml") rather 
>>than merging an additional configuration with the default one.
>Ok, my idea was the following: we have the basic sitemap language (v1.0),
>a new version 1.1, 1.2. etc. will only differ in some parts: perhaps
>a new element or a removed one etc. But not to many. So I thought
>it's much easier to describe the 1.1 language as a diff to 1.0. So
>you take 1.0 as the base and simply add/exchange the nodes that
>Actually, my first approach was to use different files, but in this
>case the files have to be more tightly bound to the tree processor.
>Currently, the user can configure which configuration file to use (which
>is imho a unneeded feature).
>If you want, we can go the way of different configuration files, but then 
>please without any user configuration to overwrite the files. 
>I don't care how we do it as long as we do it!

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 

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

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.

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.

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?


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

View raw message