Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <dev@cocoon.apache.org>
Subject: RE: [RT] Rethinking the SourceResolver concept
Date: Tue, 21 Oct 2003 09:40:41 +0200
Message-ID: <LKENJPKDAIKAPKHEOCMMIEMLFLAA.cziegeler@s-und-n.de>
MIME-Version: 1.0
In-Reply-To: <3F940244.1080106@anyware-tech.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"

Sylvain Wallez wrote:
> 
> I am strongly -1 to resolve relative URIs relatively to the position of 
> a component in the container hierarchy.
> 
I totally agree here.

<SNIP/>

> 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.
> 
Yes, that's true.

But to be honest, I'm more and more thinking that this "feature" is doing
to much in the background. Remember the thread about the "automatically
conversion from html to xml" where I was the only one liking this nice
feature and everyone else was scared to death by it (ok, a little bit
exaggerating here). I now tend more and more that this is here the same
case. If I want to write a "global" component that resolves relative
to the current sitemap than I should pass a Source object as a parameter
to this component and not the relative url.
Anyway, I agree, that changing this behaviour now is out of question,
so let's leave it as it is :) I refactored the whole thing for 2.2
and as soon as 2.2 is runnable I can finish that.

Carsten