[Zope3-dev] Re: RFC: The browser:page compromise

Philipp von Weitershausen philipp at weitershausen.de
Thu Apr 20 14:16:49 EDT 2006


Rocky Burt wrote:
> On Thu, 2006-20-04 at 19:26 +0200, Philipp von Weitershausen wrote:
>> A browser page is something that's published. It provides
>> IBrowserPublisher and returns some data to the pbulisher that's in turn
>> returned to the agent.
>>
>> A browser view is something more general. @@absolute_url is a browser
>> view. It's never pulished (you wouldn't type into a browser
>> http://.../some_obj/@@absolute_url). Rather, you use it from other
>> components.
> 
> Ok, this makes sense.  But, the "browser view" you describe (something
> never published but still looked up from code and used) is exactly how I
> tend to use template-less <browser:page>'s.

That's why the difference wasn't clear in the past. It's not your fault,
I'm blaming noone :).

To give an example, the @@plone view should really be a browser:view,
not a browser:page because it's never published. You don't type
http://.../some_obj/@@plone into the URL bar of your browser. It
wouldn't work anyways.

>> By requiring browser page classes to implement IBrowserPublisher, all
>> this will be more explicit. Of course, you can just use a convenient
>> base class and simply implement a __call__ method.
> 
> Hmm... sounds like you're making us do work.  I'm all about making
> things more explicit and the like ... but if it means doing more work,
> perhaps we should think of a way that makes things more explicit without
> requiring more work :)

I'm making you do a *little* bit more work. That doesn't mean you'll
have to implement IBrowserPublisher from scratch all the time. Just
inheriting from zope.publisher.browser.BrowserPage will be enough.
That's what base classes are for, after all. Most people inherit from
BrowserView currently anyways (I certainly encouraged that in my book),
so they'd just have to change their base class.

I consider an explicit base class an acceptable price for understanding
what the heck is going on...

Let me give you a small demonstration of the current magic and why it
makes e.g. debugging so hard.  Imagine you wonder why a certain view,
let's say @@contents.html, resolves to something that you don't expect.
So you try to debug:

  $ bin/zopectl debug
  >>> from zope.publisher.browser import TestRequest
  >>> request = TestRequest()
  >>> root
  <zope.app.folder.folder.Folder object at 0x2bfb330>

  >>> from zope.component import getMultiAdapter
  >>> getMultiAdapter((root, request), name=u'contents.html')
  <zope.app.publisher.browser.viewmeta.Contents object at 0x2084e10>

Now wtf is this object's class? You could look for it in the module
stated but of course it's not there. This module is where it was
dynamically assembled. Good luck finding the original implementation...

Philipp


More information about the Zope3-dev mailing list