[prev in list] [next in list] [prev in thread] [next in thread]
List: zope3-dev
Subject: [Zope3-dev] Re: RFC: The browser:page compromise
From: Tres Seaver <tseaver () palladion ! com>
Date: 2006-04-24 15:41:50
Message-ID: 444CF1BE.5060802 () palladion ! com
[Download RAW message or body]
-----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@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-----
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/zope3-dev%40progressive-comp.com
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic