Evan Simpson wrote:
Yuppie wrote: > 'relative to site object' is quoted from the API documentation of > absolute_url()
The API documentation is incorrect, and the docstring in the method is correct:
'''Return a canonical URL for this object based on its physical containment path, possibly modified by virtual hosting. If the optional 'relative' argument is true, only return the path portion of the URL.'''
"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.
You introduced that concept in Zope 2.7. The method docstring is part of your change. Before Zope 2.7, absolute_url was defined different, worked different and was used different in products maintained by ZC.
Current behavior looks like this:
http://localhost:8080/temp_folder/test absolute_url( ): http://localhost:8180/temp_folder/test absolute_url(1): temp_folder/test
absolute_url( ): http://www.example.com/temp_folder/test absolute_url(1): temp_folder/test
absolute_url( ): http://www.example.com/test absolute_url(1): test
absolute_url( ): http://www.example.com/foo/test absolute_url(1): foo/test
This is entirely consistent, predictable, and easy to explain. The problem you are encountering is almost certainly due to a use of absolute_url where it shouldn't be used, or is used incorrectly.
I don't think the old API was better. I'm just saying that you changed the API in a way that is not backwards compatible. I encountered the problem with a plain new CMF Site. And the use of absolute_url is consistent with Zope 2.6 API and implementation. So I don't think it's a problem of incorrect use.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce