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

[Philipp von Weitershausen]

Jan-Wijbrand Kolman wrote:
>> 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!!

No, you're actually right. The ++skin++ traversal adapter in X3.0 
actually does:

class skin(view):

     def traverse(self, name, ignored):
         self.request.shiftNameToApplication()
         self.request.setPresentationSkin(name)

         return self.context

So that's not a bad monkey then.

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

I see.

> 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.

Agreed.

> 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.

These matters here really aren't black and white. I can only express my 
opinion, which is: If we can solve compatability problems like these by 
overriding components the Zope3-style way instead of monkey patching, we 
should. IMHO monkeys are to be avoided.
The matter is also a philosophical matter as to how far we want to take 
Five. I think we are quite clear on it that we don't want to monkey 
patch Zope 2 so far that it looks like Zope 3 :). We just want to write 
Zope 3-style software, which in the end simply does @@absolute_url and 
doesn't care how the underlying implementation works.

In any case, I think you're quite right that Five should be as close to 
Zope 3 as possible, which means the IABsoluteURL view should be 
virtualhosting safe. It seems that you've found a way to do so, so I 
think you should just add the above code to Five's AbsoluteURL 
implementation. That'll avoid the monkey patch.

Philipp