cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: [RT] Rethinking the SourceResolver concept
Date Mon, 20 Oct 2003 16:11:03 GMT
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>> Unico Hommes wrote:
>>> Carsten Ziegeler wrote:
>>>> Now, I think we can make it simpler :)
>>>> 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.
>>> 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.
>>> 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.
>> I'm currenlty implementing exactly this for 2.2.
>>> 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.

I agree here.  If there's another inventive solution that'd be great 
too, but changing the whole resolving paradigm I think is too severe.


View raw message