absolute_url(1) was broken (by my definition of broken) basically since the introduction of VHM, which means the better part of 2 years. Naturally, there is code now that relies on this (broken) behavior. This does however not mean it should not be fixed!
The ugly part is that the behavior of absolute_url(1) changes suddenly when the Vhost configuration starts to include inside-out parts (_vh_xyz). This means that is is possible to break (seemingly) working code by reconfiguring Apache. :-(
I had some very bad experiences with big packages like CPS2 that suddenly exploded in my face at the worst possible time (deployment at the customer's site).
The idiom '/'+absolute_url(1) to get the path part of an object's URL is *very* common, and as luck will have it *works absolutely fine* as long as inside-out hosting is not present. So this error usually goes undetected and creeps all over people's code. I'd be willing to bet that it is possible to break other packages like, say, Plone simply by changing Vhost configs as well ;-).
Note that this is one of my main points: It will be of little use to document usage of BASEPATH1+absolute_url(1) when '/'+absolute_url(1) appears to work (until it is far too late).
Once you have a big package poisoned like this, all you can basically do is monkey-patch absolute_url() which is what I had to do on several occasions.
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().
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.
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).
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.
Regards, Stefan
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.
On Montag, Dez 8, 2003, at 07:53 Europe/Vienna, Evan Simpson wrote:
Yuppie wrote:Yes. getIcon() is the cause of the problem I see:
To access the ZMI I use this Apache rule:
ProxyPass /zope27 http://localhost:8080/VirtualHostBase/http/example.org:80/ VirtualHostRoot/_vh_zope27 getIcon() for a folder in myCMFSite returns 'zope27/myCMFSite/folder_icon.gif'
(was 'myCMFSite/folder_icon.gif' in Zope 2.6)
OFS/dtml/main.dtml adds BASEPATH1, so the URL is '/zope27/zope27/myCMFSite/folder_icon.gif'
(would be '/zope27/myCMFSite/folder_icon.gif' in Zope 2.6)
Based on this, and on a lot of back-burner pondering, I'm now thinking that the proper fix for this is the one you suggest. It makes sense for the relative version of the absolute path to omit BASE1, the URL of the virtual root, returning the semantics of absolute_path(1) to "path relative to the virtual root". Use cases that need a hostname-relative URL can use BASEPATH1 + absolute_url(1).
Cheers,
Evan @ 4-am
-- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
