[z3-five] Re: implementing IBrowserRequest not enough?

[Jan-Wijbrand Kolman]

> Five's monkey patch is pretty unnecessary. [g|s]etPresentationSkin is 
> not used in Zope 3 (not used meaning not used in production code; i 
> think it's only there for test code; afaik it never was in interfaces 
> and it's been removed from the trunk).
> 
> As for the rest of the interface, one would have to compare. But I think 
> the bulk amount of methods and attributes are the same.

Actually, I could be all wrong here indeed. Zope-3 and using it through Five is 
still fairly new to me.

But if I try to understand what the interfaces IRequest, IHTTPRequest, 
IApplicationRequest, IHTTPApplicationRequest, IBrowserRequest and 
IBrowserApplicationRequest define, I come to the conclusion that Zope-2's 
HTTPRequest does not implement all of it...

Another question would be, though maybe not for this thread, is how to get and 
set the Presentation skins in a more Zope-3-ish way then :) We are actually 
using setPresentationSkin for a project where we create alternative views for 
Silva content. If there's another 'de facto standard' way of setting a skin then 
I'd be very curious for it!!

> I'm not sure what you need your custom IAbsoluteURL view to do. Virtual 
> hosting in Zope 2 is delegated by a Virtual Host Monster which mangles 
> the obj.absolute_url() method transparently. Since 
> Five.browser.AbsoluteURL uses that good ol' method, I don't see why it 
> wouldn't be virtual-host-aware. Probably I'm missing something.
> 
> I personally would like to keep the amount of monkeys in Five at a 
> minimum. So, when in doubt and when we have the choice, I'd prefer using 
> customizable Zope3-style components, e.g. in this case provide an 
> alternate implementation of IAbsoluteURL. But again, I might be missing 
> the point, so convince me otherwise :).

I think I know how the VHM works :)

The generated URLs are indeed not the problem, they are correct. In Zope-3, the 
default implementation of IBrowserRequest.breadcrumbs() knows when to stop 
crawling up the tree, namely, when the current context is the VirtualHostRoot:

zope/app/traversing/browser/absoluteurl.py:
...
         if sameProxiedObjects(context, request.getVirtualHostRoot()) or \
                isinstance(context, Exception):
             return ({'name':'', 'url': self.request.getApplicationURL()}, )
...

Five/trunk/browser.py will not do that and keep crawling up to the Zope root.

I think the default behaviour of Five's implementations of interfaces defined by 
Zope-3 should be as close as possible to the default implementation of Zope-3.

But still, yes, I'm able to override the registration of Five's AbsoluteUrl 
adapter/view with my own 'virtual host aware' implementation of IAbsoluteUrl in 
my own product. Something like:

     def breadcrumbs(self):
         context = self.context.aq_inner
         container = context.aq_parent
         request = self.request

         name = context.get_short_title()

         if container is None or self._isVirtualHostRoot() \
             or not ITraversable.providedBy(container):
             return ({'name': name,
                      'url': context.absolute_url()
                      },)

         view = getViewProviding(container, IAbsoluteURL, request)
         base = tuple(view.breadcrumbs())
         base += ({'name': name,
                   'url': ("%s/%s" % (base[-1]['url'], name))
                   },)

         return base

     def _isVirtualHostRoot(self):
         virtualrootpath = self.request.get('VirtualRootPhysicalPath', None)
         if virtualrootpath is None:
             return False
         context = self.context.aq_inner
         return context.restrictedTraverse(virtualrootpath) == context

And again, I'm still trying to find out how things ideally should be done in 
ZOpe-3/Five land, so maybe I'm looking for solutions in the wrong direction.


regards
jw

-- 
Jan-Wijbrand Kolman
jw at infrae.com