-----BEGIN PGP SIGNED MESSAGE-----
Philipp von Weitershausen wrote:
> Bernd Dorn wrote:
>>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
> Perhaps I should mention these points in the proposal. I will update it
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
> 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").
>>"""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*.
> 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
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
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
-----END PGP SIGNATURE-----
Zope3-dev mailing list