Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Yes, I think migrating everything is the only way :(Hi all,
In preparation to the Fortress migration, I'm currently moving all TreeProcessor code to ServiceManager/ServiceSelector, doing also some code simplification along the way.
I found some places however where strong dependencies on ComponentManager/ComponentSelector exist:
1/ AbstractProcessingPipeline, which relies on Recomposable to know where to get the pipeline components from.
2/ SitemapComponentSelector/OutputComponentSelector which provide additional methods to the raw ComponentSelector
The current solution for 1/ is to use a WrapperComponentManager to translate SM->CM. This allows moving this part to SM later.
For 2/ however, moving to SM is more difficult, as it means changing the base interface to ServiceSelector to avoid these objects to be wrapped in a ServiceSelector that would hide the additional methods.
The only solution I see so far is to migrate the whole thing (i.e. pipelines included) to ServiceManager, but this means changing some base classes in lot of places. I consider all these classes to be internal to the Cocoon engine, but some advanced users out there may have written their own pipeline implementations that will be broken with these changes.
Most classes are really internal and I think that we could "hide"
most incompatible changes in the abstract pipeline class, so
if you inherit from that one, there shouldn't be so many
changes to do for users.
I doubt there are (m)any custom pipeline implementations out there. I think it shouldn't be a consideration if it means sacrificing code transparency. Not that I am saying it I think it will (don't know), but if it helps to make the code cleaner or better I prefer incompatible changes.
Btw. The only code I use from the treeprocessor is the variable resolver stuff. I think this code is of general enough interest to dedicate its own subpackage for (away from treeprocessor). I noticed Carsten currently has duplicated that code in the portal block. WDYT?
-- Unico
