Hi Philipp > -----Original Message----- > From: Philipp von Weitershausen [mailto:[EMAIL PROTECTED] > Sent: Saturday, April 22, 2006 9:15 AM > To: [EMAIL PROTECTED] > Cc: zope3-dev@zope.org > Subject: Re: RFC: The browser:page compromise > > [EMAIL PROTECTED] wrote: > >>> That confuses me even more. I *am* proposing changes to the > >>> browser:page directive... > >> Hmm, never mind. I think I understand what you mean. You'd like to > >> see new directives, instead of changing the old ones. Right? > > > > Yes, I think it's very important to bring a little stability to the > > Zope3 framework rather then change every release such fundamental > > parts like directives. > > I will accept this criticism when you tell Jim that his work > on jim-adapter branch was wrong for that same reason and when > you tell me (which you haven't) that my work on > MakeZopeAppSmaller is also wrong for that reason.
That's a difference. Jim's *adapter* refactoring will bring us a speed up and solves some problems in the adapter registry implementation. (lookup multiadapter by it's registration tuple). Your proposal is just a *cosmetic* change which forces us to change existing projects and like Florent says: We have to write additional python classes for just that. I don't buy this as really usefull. > Sorry, I just don't buy it. We're still refactoring some key > packages like zope.component and you're trying to shoot down > a refactoring of 3 ZCML directives? Yes, Why the hell do I have to write additional python classes for each page registration after your refactoring? I don't by this as a improvment. If we do this, I can add the browser:page directive back as a high level directive and then the need for write additional python classes is just a YAGNY like before. Is this really a improvment? Another problem is, that we have mor then 6 projects build with zope3 up and running. Such a improvment is not nice and will force us to change more then ~300 existing page registrations. It's a horror to think about how many python class we have to write if we do this simplification!!! You totaly ignore that Zope3 is not a experimental framework now and stability is also a criteria which should recognized. Please recognize that some people have built applications with zope3 since more then 2 years now. And respect that they are not willing to just change everything wich forces them to go other ways then before without a real *improvment*. btw, I don't dislike the refactoring at all, but I just dislike that we have to update our projects for *this* simplification. We have at least to provide both way of registration. Perhaps it's really time to add a higher level directive pool for such refactorings. Is this a option for you? Regards Roger Ineichen > Philipp > > _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com