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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Philipp von Weitershausen wrote:
> 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.

I would point out that the *existence* of the new class is an
implementation detail, of which end users can remain blissfully
ignorant.  The users who get bit are the ones who want *both* the
convenience of the current directive's semantics *but* want to be able
to override some of the ways those "implementation details" work.  Such
users probably need to forego the convenience, and settle instead for
implementing their *own* directive, which does what they want.

I would argue, BTW, that if we are going to get rid of directives,
'browser:view' is a lot better candidate than 'browser:page':  I would
bet that 99% of the third-party Zope3 application code in the wild
*never* users 'browser:view', and that the authors of the 1% are the
same ones who are involved (or should be) in this debate.

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

We need to take that cost into account more clearly, because we are
trading off *other people's cossts* for our own benefit (increased
maintainability, new features, or "I just like it better").

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

It is *not* an implementation detail for the application develo9per:  it
is part of the public API of the directive.  I would bet again that the
percentage of "deployed-in-the-wild third-party-application directives"
which do *not* use templates is *tiny*.

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

Directives matter to the *user*;  what the underlying wiring ends up
looking like is *irrelevant* to the user, as long as the semantics are
satisfied.


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFETPG++gerLs4ltQ4RAodRAJ4jwkioSXiANAZblEMD2Y+K+5SZVwCgqcRc
fTbqXb23OhR2mHQLBQ+KLRc=
=Jshl
-----END PGP SIGNATURE-----