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

Rocky Burt rocky.burt at adaptivewave.com
Thu Apr 20 14:28:35 EDT 2006


On Thu, 2006-20-04 at 20:16 +0200, Philipp von Weitershausen wrote:
> > 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 :).

Ahh, ok, so <browser:page>'s are always assumed to have some sort of
__call__ that would be executed upon publishing even if often times
people used template-less <browser:page>'s that are never published nor
have __call__ defined.

So basically I've been using template-less <browser:page>'s in most
cases where I should have used <browser:view> even though <browser:page>
did what I wanted it was inappropriate use.

And now you're saying that since <browser:view> has nothing to do with
publishing, it should probably be simply <view> ... if all of my
statements are correct, everything makes soooo much more sense now :)


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

Ah right.  Ok, this makes more sense now and can understand where its
necessary.


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

Right, and now I do too :)


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

I absolutely see your point here and now agree wholeheartedly with why
its necessary to make these things more explicit.  No more magical
classes :)

+1 to the overview of your proposal even if I'm just learning things
here :)


- Rocky

-- 
Rocky Burt
AdaptiveWave - Content Management as a Service
http://www.adaptivewave.com
Content Management Made Simple




More information about the Zope3-dev mailing list