Rocky Burt wrote: > On Thu, 2006-20-04 at 18:56 +0200, Philipp von Weitershausen wrote: >> http://dev.zope.org/Zope3/TheBrowserPageCompromise >> >> I've long been thinking about how to make <browser:page /> simpler and >> less magical. Some radical ideas weren't received well and I couldn't >> convince even myself 100% that they were the way to go. Other >> brainstormings were dead ends. >> >> I therefore call this proposal a compromise. It simplifies, but it >> shouldn't annoy (Tres...). Note that I'm specifically only addressing >> <browser:page />, not <browser:view />; nor am I coming up with a >> framework for dealing with forms and their handlers (Jeff...). >> >> 'Nuff said. Your turn :) > > I have a few naive comments/questions. Could you quickly explain in 2 > lines or less what the difference between <browser:page> and > <browser:view> is?
Right now the difference is subtle. Too subtle, I'd say. With my proposal it'll be clearer :). A browser page is something that's published. It provides IBrowserPublisher and returns some data to the pbulisher that's in turn returned to the agent. A browser view is something more general. @@absolute_url is a browser view. It's never pulished (you wouldn't type into a browser http://.../some_obj/@@absolute_url). Rather, you use it from other components. > To be frank, I've only ever used <browser:page> and its done what I > wanted quite nicely from having class-less templates, and template-less > classes, and classes+templates. The magic that you seem to describe is > an implementation detail that I could care less about as a user of the > functionality (perhaps if I were more involved with the coder underneath > I would care more). It's not an implementation detail. After all, you're deciding whether to use a template or not. My goal is clarity in Python. So I'm writing a class which doesn't have *any* publishing information yet the pbulisher expects that. I can't just go in a test and say zope.component.provideAdapter(MyBrowserPageClass) currently and the page will be publishable (which is something different than just an adapter lookup). Why isn't it publishable? Because it doesn't have that functionality; <browser:page /> adds it magically in a dynamically created subclass. That sucks. By requiring browser page classes to implement IBrowserPublisher, all this will be more explicit. Of course, you can just use a convenient base class and simply implement a __call__ method. I think it'll be simpler and clearer what goes on with the proposal in place. > So... having said all that, I have to say I don't see much benefit in > what your RFC suggests but rather just a little added complication. The benefit is less magic in ZCML and more clarity in Python. Philipp _______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com