[Zope-dev] Re: Bug in AbsoluteURL Adapter

[Christian Zagrodnick]

On 2007-11-28 19:52:49 +0100, Philipp von Weitershausen 
<philipp at weitershausen.de> said:

> On 28 Nov 2007, at 12:54 , Daniel Havlik wrote:
>> Am 28.11.2007 um 12:01 schrieb Philipp von Weitershausen:
>>>> The problem we tried to solve was: We have a structure of Plone  
>>>> content objects. We wanted to access a particular one in a view  which 
>>>> can be called anywhere. Therefore we registered this content  object as 
>>>> an utility. It turned out, that this utility does not  have a request 
>>>> after fetching it in our view with getUtility().  The request is needed 
>>>> to get an absolute URL of our content object.
>>> 
>>> This is what I don't understand: why should content objects have  
>>> access to the request? I understand that the request is needed in  
>>> order to compute the absolute URL, but the IAbsoluteURL adapter is  a 
>>> *multi*-adapter for (context, request). So it will always receive  the 
>>> request explicitly in its constructor. This pattern is the  foundation 
>>> of separating content from presentation: the content  object is 
>>> request-unaware, the adapters and views around it are  request-aware.
>> 
>> Exactly, thats why we thought this may be a bug. The __str__ method  of 
>> Five's AbsoluteURL adapter does not make use of the request the  
>> adapter gets in its constructor, it just calls the zope2-ish  
>> absolute_url() method on the context. (Which itself relies on the  
>> REQUEST attribute of the object to convert the path to an URL)
> 
> I see what you mean now. In that case I agree that it would be  
> "cleaner" to use the adapter's request, *IF*  
> request.physicalPathToURL(obj.getPhysicalPath()) will always yield the  
> same as obj.absolute_url(), especially regarding virtual hosting, etc  
> (if we don't have tests for that yet, creating some would be extremely  
> good).
> 
> If the improved version of the adapter will also fix a few problems  
> when used with Plone, it would still be good to have tests that  
> provoke such circumstances and verify that the new implementation is  
> indeed better.

I think the real problem here is that when you register a content 
object as utility that it is either acquition wrapped or not. If it is 
not wrapped I don't really see how to get the physical path in Z2. If 
it is wrapped you'll probably have fun with pickling acquisition 
wrappers.



-- 
Christian Zagrodnick

gocept gmbh & co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891