Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:Not exactly :) As far as I remember, we wanted to change the version number
Sylvain Wallez wrote: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.
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.Carsten,
I noticed you added support for sitemap language versionning in the TreeProcessor a few weeks ago. What's the purpose of this?
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 number...
<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 :)
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 "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
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 definitions.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
