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 _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com