Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <dev@cocoon.apache.org>
Subject: RE: Sitemap versionning in TreeProcessor?
Date: Fri, 16 Jul 2004 10:01:43 +0200
Organization: S&N AG
MIME-Version: 1.0
In-reply-to: <40F788D2.5000003@apache.org>
Thread-Index: AcRrCC6pgxubU7HnRYObrTlgsYotAQAAgw9w
Message-ID: <OF4632A43D.62AF6736-ONC1256ED3.002B1C47@sundn.de>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"

Sylvain Wallez wrote:
> 
> Carsten Ziegeler wrote:
> 
> >Sylvain Wallez wrote:
> >
> >  
> >
> >>Carsten,
> >>
> >>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.
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.

> <SNIP/>
> 
> 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 
> 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.
Great! So we have the behaviour back we had with our XSLT sitemap
implementation :)

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

> 
> 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 
> "org.apache.cocoon.components.treeprocessor.TreeBuilder/sitemap-1.0" 
> 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

Carsten