-----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 [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 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/archive%40mail-archive.com