[Zope-dev] Zope 2.7.0 b3 regressions

[Paul Winkler]

On Mon, Dec 08, 2003 at 07:14:28PM +0100, Stefan H. Holek wrote:
> After reading this paragraph for the third time I realized you have a 
> very good point here.
> 
> But
> 
> <quote by="Evan Simpson">
> "Relative" in this context refers to the concept of a "relative path" 
> as used in rfc1808, not to a relationship with a Zope object.  It is 
> meant for use in situations such as redirection to a secure page from 
> an insecure one (eg. 'https://example.com' + target.absolute_url(1)) 
> where you would otherwise have to generate the complete URL and then 
> break it apart.
> </quote>
> 
> So, what do we want "relative" to mean for absolute_url?

Speaking for myself, what I really want is something that always 
works for the client, since that's who generally cares about URLs.
I like the behavior of Evan's fix. For looking up objects in zope,
we should use other methods such as getPhysicalPath().
Lennart's path2url() would be handy.

But I don't think it's worth the backward compatibility pain
to change absolute_url(1) now.
We've been waiting ages for a stable Zope 2.7, IMHO it's too late 
for something this problematic to change.

So my proposal is this:

1) Implement distinct methods for client-useable virtual paths
vs. server-useable containment paths, as Lennart proposes.

2) absolute_url(1) in Zope 2.7 should continue to work as 
in <= 2.6. 

3) As soon as we decide conclusively what is going to happen
with absolute_url(1) in zope 2.8, we can have it log a deprecation 
warning.  (Hmm, that could really annoy admins. A deprecation
warning on every call to getIcon(), ugh. Other ideas?)

4) In zope 2.8, we have the new behavior, whatever we decide that is.

We also have to be sure to update the Help docs
and the long-suffering API Reference.

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's LIUTENANT ON WHEELS!
(random hero from isometric.spaceninja.com)