[Zope-dev] Re: Zope 2.7.0 b3 regressions

[Leonardo Rochael Almeida]

On Mon, 2003-12-08 at 09:35, Stefan H. Holek wrote:
> [...]
> So by my definition, the URL (relative or not) should *always* include  
> eventual _vh_xyz parts. If what one really needs is related to the  
> physical layout of the ZODB, there is always getPhysicalPath().

+1

> URLs are in fact just some whack attributes of objects, and objects can  
> have more than one URL at any time, depending on Vhost configs *only*.  
> URLs are a function of the current REQUEST (traversal) and do represent  
> little information with regard to an object's location in the ZODB.

+1

> I see the main issue here in that the concepts of URL and physical  
> location are not well separated (CMF's getIcon() attempting to use URLs  
> to locate objects for example).

IMHO, this is broken behaviour. If you try to use an URL to locate an
object, the only sane behaviour is to feed this URL to an URL api
(probably in the REQUEST object) to get it mapped to a physical path.

> Should this be your last word on this I am with Lennart in that we have  
> to think about a whole new class of API methods for URL information.

I think this should be done anyway, because of backward compatibility
problems. Really, I think it's ok if at some point we simply say "hey,
now we'll use this new API because that old API was broken and people
relied on the broken behaviour". This is certainly better than pulling
people's rug under their feet. We could then start deprecating the old
API and eventually pull it away, if the arrival of Zope3 doesn't obviate
it anyway :-)


> P.S.: I have written a bunch of regression tests for absolute_url  
> behavior over the weekend and if nobody tells me otherwise am going to  
> check them into Products/SiteAccess/tests.

+5 Yes, please!

As the author of ASP404, I'd really like to be able to rely on Zope's
virtual hosting behaviour.

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.