Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Actually, it's a feature we wanted to use for 2.1 already... A long timeCarsten,
I noticed you added support for sitemap language versionning in the TreeProcessor a few weeks ago. What's the purpose of this?
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
differ.
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 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.
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 "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?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
