Unico Hommes wrote:
Carsten Ziegeler wrote:I'm currenlty implementing exactly this for 2.2.
Now, I think we can make it simpler :)I fear this as well but think it will make the contract much clearer too, so I would be in favor of changing the behavior in this way.
a) A sitemap component gets a Cocoon source resolver anyway.
We can provide in the setup() method a wrapper for
the Avalon SourceResolver that knows it's sitemap. This
is simply and doesn't need thread locals etc. anymore.
b) The only problem lies in all this nice little thread
safe components that resolve URIs relative to the
current sitemap. One solution for b) is to say, relative paths are always
resolved to the context directory of cocoon than we can
remove a lot of the hacky things. But I fear this might
break some things.
The way I understand it is that cocoon has a hierarchical containment model. The root container manages components declared in cocoon.xconf and the child containers each manage the components of the sitemap they represent. A SourceResolver is contextualized against the current sitemap (= container context managing the sitemap components). Therefore it means that each container in the hierarchy should provide its own SourceResolver contextualized relative to its own context instead of following the traditional ECM paradigm of inheriting all components it does not specifically declare itself from the parent container.
Hmm. But shouldn't *any* contextualizable component that lives in a hierarchical containment model *always* be contextualized against the container it was looked up on? Shouldn't that actually be part of the Contextualizable contract? I would say that goes without saying (no pun intended :-). What about components that have a dependency on components that are contextualizable? ad infinitum?This is exactly the problem. You define a nice service that takes in any uri (relative and absolute). This service is defined at the root CM but is called from everywhere, so e.g. from a sub sitemap. Now, in order to work correctly this nice service has to know the context of the sub sitemap (ok, not this service by itself, but the source resolver the service uses).
Carsten
I am strongly -1 to resolve relative URIs relatively to the position of a component in the container hierarchy.
Let's look at an example to see how deeply it can break things and make prediction of the application's behaviour difficult. Imagine a component that operates on some kind of configuration data. It expects that data URI as a String argument and resolves it internally.
Suppose we have defined the component in cocoon.xconf (the toplevel container): relative URIs are considered as rooted to the webapp context. Now, in a particular area of the application, we want to refine this component with some additional configuration. So we redefine the role in <map:components> (or in the future COB-INF/block.xconf). From that moment on, relative URIs passed to the newly defined component are resolved relatively to the sitemap (or block) mount point. Bing, application broken!
IMO, we must keep the current behaviour. This allows all components to automatically adapt to the mount point of the current sitemap (or block). And if a component doesn't support mountpoint-relative URIs, then its methods should use a Source object instead of a String, thus requiring the caller to resolve the URI.
Don't know if I was clear, but I think changing the resolution behaviour will cause a lot more harm than good. And if a global ThreadLocal is the price to pay, let's pay it.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
