cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <>
Subject Re: Migrating Processor & Pipeline to ServiceManageable
Date Sat, 10 Jul 2004 09:39:10 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>>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.
>Yes, I think migrating everything is the only way :(
>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 

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?


View raw message