Daniel Fagerstrom wrote: >> > Ok, I guess that we have to go for your solution of having several > variants of the source resolver: > > SourceResolver.ROLE + "/static" - resolve relative to the defining > manager, and is implemented as I indicated above. We could modify > CoreComponentManager so that it automatically creates static resolver > for each manager. > > SourceResolver.ROLE + "/dynamic" - resolve relative the current sitemap > and uses EnvironmentHelper.resolveURI (or something similar), undefined > and throws an exception if used when there is no current processor. > > Then we should try to change all uses of the current source reolver to > the new ones and in principle deprecate the CocoonSourceResolver, > (although a warning in the documentation might be enough). > > WDYT? > Why different components? What about using different protocols? Without a protocol you have the same behaviour as currently and using "static:" (or a better name) it's resolved relative to the definition. So no changes of the existing components. Just a protocol switch where appropriate.
Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
