Re: [Zope3-dev] RFC: The browser:page compromise

2006-04-25 Thread Lennart Regebro
On 4/25/06, Bernd Dorn <[EMAIL PROTECTED]> wrote: > > On 25.04.2006, at 20:27, Lennart Regebro wrote: > > > At https://svn.z3lab.org/z3lab/hello/trunk there is now a page > > this url seems to be broken No, it works fine, but only for svn > > (If you don't want to check it out and test it, you c

Re: [Zope3-dev] RFC: The browser:page compromise

2006-04-25 Thread Bernd Dorn
On 25.04.2006, at 20:27, Lennart Regebro wrote: At https://svn.z3lab.org/z3lab/hello/trunk there is now a page this url seems to be broken implementation that is easy to use and doens't do class generation. In fact, there are two versions, one that sets the __call__ attribute during instan

Re: [Zope3-dev] RFC: The browser:page compromise

2006-04-25 Thread Lennart Regebro
At https://svn.z3lab.org/z3lab/hello/trunk there is now a page implementation that is easy to use and doens't do class generation. In fact, there are two versions, one that sets the __call__ attribute during instantiation, and one that uses browserDefault() and publishTraverse(). There is also an

Re: [Zope3-dev] RFC: The browser:page compromise

2006-04-25 Thread Jim Fulton
Philipp von Weitershausen wrote: Jim Fulton wrote: The browser2:pageTemplate and browser2:pagesFromClass directives don't really gain anything, because they still generate classes. They don't have to generate classes. They could just do clever factory construction to avoid class creation. I

Re: [Zope3-dev] RFC: The browser:page compromise

2006-04-25 Thread Philipp von Weitershausen
Jim Fulton wrote: The browser2:pageTemplate and browser2:pagesFromClass directives don't really gain anything, because they still generate classes. They don't have to generate classes. They could just do clever factory construction to avoid class creation. I don't think they can. browser2:pageT

Re: [Zope3-dev] RFC: The browser:page compromise

2006-04-24 Thread Jim Fulton
Philipp von Weitershausen wrote: http://dev.zope.org/Zope3/TheBrowserPageCompromise I've long been thinking about how to make 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

Re: [Zope3-dev] RFC: The browser:page compromise

2006-04-22 Thread Lennart Regebro
I'm -1 on this proposal. I agree, browser:page is too complex and magic. The reason for it's complexity and magic is that there are two things that clash: 1. The need to have simple and easy view registrations, and 2. The requirement that view must be callable classes. The second requirements mea

Re: [Zope3-dev] RFC: The browser:page compromise

2006-04-22 Thread Philipp von Weitershausen
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

Re: [Zope3-dev] RFC: The browser:page compromise

2006-04-20 Thread Bernd Dorn
On 20.04.2006, at 18:56, Philipp von Weitershausen wrote: http://dev.zope.org/Zope3/TheBrowserPageCompromise I've long been thinking about how to make 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. Othe

[Zope3-dev] RFC: The browser:page compromise

2006-04-20 Thread Philipp von Weitershausen
http://dev.zope.org/Zope3/TheBrowserPageCompromise I've long been thinking about how to make 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 propos