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

> 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
Content Management Made Simple

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to