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

[Philipp von Weitershausen]

Rocky Burt wrote:
> On Thu, 2006-20-04 at 18:56 +0200, Philipp von Weitershausen wrote:
>> http://dev.zope.org/Zope3/TheBrowserPageCompromise
>>
>> I've long been thinking about how to make <browser:page /> simpler and
>> less magical. Some radical ideas weren't received well and I couldn't
>> convince even myself 100% that they were the way to go. Other
>> brainstormings were dead ends.
>>
>> I therefore call this proposal a compromise. It simplifies, but it
>> shouldn't annoy (Tres...). Note that I'm specifically only addressing
>> <browser:page />, not <browser:view />; nor am I coming up with a
>> framework for dealing with forms and their handlers (Jeff...).
>>
>> 'Nuff said. Your turn :)
> 
> I have a few naive comments/questions.  Could you quickly explain in 2
> lines or less what the difference between <browser:page> and
> <browser:view> is?

Right now the difference is subtle. Too subtle, I'd say. With my
proposal it'll be clearer :).

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.

> To be frank, I've only ever used <browser:page> and its done what I
> wanted quite nicely from having class-less templates, and template-less
> classes, and classes+templates.  The magic that you seem to describe is
> an implementation detail that I could care less about as a user of the
> functionality (perhaps if I were more involved with the coder underneath
> I would care more).

It's not an implementation detail. After all, you're deciding whether to
use a template or not.

My goal is clarity in Python. So I'm writing a class which doesn't have
*any* publishing information yet the pbulisher expects that. I can't
just go in a test and say
zope.component.provideAdapter(MyBrowserPageClass) currently and the page
will be publishable (which is something different than just an adapter
lookup). Why isn't it publishable? Because it doesn't have that
functionality; <browser:page /> adds it magically in a dynamically
created subclass. That sucks.

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.

I think it'll be simpler and clearer what goes on with the proposal in
place.

> So... having said all that, I have to say I don't see much benefit in
> what your RFC suggests but rather just a little added complication.

The benefit is less magic in ZCML and more clarity in Python.

Philipp