Hi there, while using the AbsoluteURL Adapter in a view, it only returns the path of the object, not the URL. This is because the object does not have a request and therefore the method absolute_url() used by the adapter cannot call the physicalPathToURL() method. Because we always have the request object in this adapter we can call the physicalPathToURL() method directly and convert the physical path of the object and return it. Here is a diff with the fix: Index: browser/absoluteurl.py =================================================================== --- browser/absoluteurl.py (Revision 81990) +++ browser/absoluteurl.py (Arbeitskopie) @@ -35,8 +35,8 @@ self.context, self.request = context, request def __str__(self): - context = aq_inner(self.context) - return context.absolute_url() + path = self.context.getPhysicalPath() + return self.request.physicalPathToURL(path) __call__ = __str__ Any comments? -- Sebastian Wehrmann gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale · germany www.gocept.com · work. +49 345 122988912 · fax. +49 345 12298891
Sebastian Wehrmann wrote:
while using the AbsoluteURL Adapter in a view,
By the way, you're using Five's AbsoluteURL adapter. (It's different from the one in Zope 3). Also, the patch below seems to be for Five. Would be good to mention that :).
it only returns the path of the object, not the URL. This is because the object does not have a request and therefore the method absolute_url() used by the adapter cannot call the physicalPathToURL() method.
Because we always have the request object in this adapter we can call the physicalPathToURL() method directly and convert the physical path of the object and return it.
Here is a diff with the fix:
Index: browser/absoluteurl.py =================================================================== --- browser/absoluteurl.py (Revision 81990) +++ browser/absoluteurl.py (Arbeitskopie) @@ -35,8 +35,8 @@ self.context, self.request = context, request
def __str__(self): - context = aq_inner(self.context) - return context.absolute_url() + path = self.context.getPhysicalPath() + return self.request.physicalPathToURL(path)
__call__ = __str__
Any comments?
Can you round up a test that demonstrates how the current implementation fails to cover your case and how your suggestion change fixes that?
Philipp von Weitershausen schrieb:
Sebastian Wehrmann wrote:
while using the AbsoluteURL Adapter in a view,
By the way, you're using Five's AbsoluteURL adapter. (It's different from the one in Zope 3). Also, the patch below seems to be for Five. Would be good to mention that :). You are right. I forgot to mention it because the mail was originally for the Five mailing list, which does not exist anymore, though.
Any comments?
Can you round up a test that demonstrates how the current implementation fails to cover your case and how your suggestion change fixes that? While trying to write a test it turned out, that it's not a problem in Five but in the interaction between Plone3 and Zope2/Five.
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. We solved the problem temporarily with an adapter which overrides Five's AbsoluteURL adapter which contains the code from the patch. Anybody an idea how to do this in a better way? -- Sebastian Wehrmann gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale · germany www.gocept.com · work. +49 345 122988912 · fax. +49 345 12298891
On 28 Nov 2007, at 11:45 , Sebastian Wehrmann wrote:
Can you round up a test that demonstrates how the current implementation fails to cover your case and how your suggestion change fixes that? While trying to write a test it turned out, that it's not a problem in Five but in the interaction between Plone3 and Zope2/Five.
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.
Hi, 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) Bye, Daniel
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.
On 2007-11-28 19:52:49 +0100, Philipp von Weitershausen <philipp@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
participants (4)
-
Christian Zagrodnick -
Daniel Havlik -
Philipp von Weitershausen -
Sebastian Wehrmann