Unico Hommes wrote:
Carsten Ziegeler wrote:
<snip/>
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 changes.
Ok, same thoughts here. I will move the whole thing to Serviceable.
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?
I use the variable resolver also ;-) For now I changed it so that it accepts both ServiceManager and ComponentManager.
IMO, we should not make a component with the variable resolver, but some utility class providing some common base resolution (e.g. input modules) yet allowing extensions in the places where it is used (e.g. named anchors and parent stack in the sitemap).
How does this sound?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
