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

[Philipp von Weitershausen]

Bernd Dorn wrote:
>> http://dev.zope.org/Zope3/TheBrowserPageCompromise

[snip]

> -1
> 
> In the Proposal you say:
> 
> "Why is this a problem? Because certain behaviour is mixed into the
> class created on-the-fly. This behaviour is not apparent in our view
> class, yet we assume it exists. It's magic."
> 
> For me this is not a reason to change/add directives. This just results
> in more work for keeping track with the zope3 releases in
> client-projects. It is ok to improve things, but this is no improvement
> for end users IMHO.

If I saw no improvement for the end user, I would certainly not have
written this proposal. The maintainability of the current code (which is
horrid) is just a very minor factor.

The dynamic creation of new classes make it *very* hard to understand
what's going on:

* Page classes don't need an __init__ or anything like that, it's
received magically.

* Page classes don't need to bear any notion that they are going to be
publishable. This has led to the lack of understanding (among core
developers!) what the difference between a mere browser view and a
browser page is. (This is probably the best "proof" that the current
system is confusing and lacks clarity.)

* The resulting class doesn't exist anywhere (because it's dynamically
created). This makes debugging very hard. See example mentioned in
http://mail.zope.org/pipermail/zope3-dev/2006-April/019169.html.

Perhaps I should mention these points in the proposal. I will update it
later.

> This reminds me of the deprecation of the vocabulary
> directive, which is also just a burden for end users (i've missed that
> discussion).

Any deprecation is a burden on the "end user" in the sense that code has
to be fixed. We can't get anywhere if we don't accept that.

> and:
> """Browser "pages" are essentially just adapters to the Component
> Architecture. Implementation details (template or not, etc.) should not
> be of much interest during the registration."""
> 
> I don't think that the template is an implementation detail. IMHO For a
> high level user the adapters are an implementation detail.

I'm not quite sure what you mean by that. To the publisher, to the
comopnent architecture and to ZCML, the fact that a browser page is
using a Page Template or something else to render HTML should be
immaterial. It's an implementation detail of the browser page itself.

Example::

  class HelloPage(zope.formlib.Page):
      def __call__(self):
          return u'<p>Hello World</p>'

  class HelloTemplatePage(zope.formlib.Page):
      __call__ = ViewPageTemplateFile('helloworld.pt')

  class HelloWhatEverPage(zope.formlib.Page):
      def __call__(self):
          return something_that_is_html

To ZCML, these pages are all the same. It shouldn't matter to ZCML
what's behind a page.

Philipp