[EMAIL PROTECTED] wrote: >> [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).
That's just the first part of jim-adapter branch. The second part is a very different (and much simpler) API for local registration. Code that uses the old API will see lots of deprecation warnings. > 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. Florent? I must have missed his reply... You don't seem to understand my proposal, though. You WON'T have to write additional python classes. That statement just isn't true. >> 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? You don't! > 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 don't have to! You got my proposal 100% wrong. My proposal will never make you write new classes (that's the compromise!): a) If you have a page tempalte without a class, you can continue like that. Just use browser2:pageTemplate instead of browser:page b) If you already have a class, you just need to make sure it's a proper browser page (IPage/IBrowserPage conformity). Then use browser2:page instead of browser:page. c) If you have a class and a template, put the template on the class via ViewPageTemplateFile and use browser2:page instead of browser:page. d) If you have a class from which several pages are created (from different methods, perhaps), use browser2:pagesFromClass instead of browser:pages. In cases a) and d), you will simply have to switch to a different ZCML directive. In cases b) and c) minor adjustments to classes are necessary, mostly the classes have to be given a (different) base class. > You totaly ignore that Zope3 is not a experimental framework > now and stability is also a criteria which should recognized. Then let's call of all improvements that will lead to deprecation of APIs and directives. I don't think that's a very sane way to go. > Please recognize that some people have built applications > with zope3 since more then 2 years now. So have I. > And respect that they are not willing to just change everything wich > forces them to go other ways then before without a real > *improvment*. Perhaps we measure improvement differently. My proposal states a bunch of problems which will be gone when the proposal is implemented. To me, that's improvement. > btw, I don't dislike the refactoring at all, but I just dislike > that we have to update our projects for *this* simplification. I realize that. Hence I've changed the proposal to suggest separate directives. They're also already implemented. See my Update post to zope3-dev. > 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? No. ZCML is not a high level thing. Jeff shell explains this very well in http://griddlenoise.blogspot.com/2006/03/zcml-needs-to-do-less.html. Bottom line: If we want something high-level with lots of automation etc., then we should simply use Python for configuration. One of my regular readings is http://thedailywtf.com, mostly because it's amusting. The other day I saw a post (http://thedailywtf.com/forums/69415/ShowPost.aspx) which reminded me very much of ZCML: ZCML tries to be so flexible and high-level and provide so much automation, that in itself is adopting features from Python. Just remember the zcml:condition feature that we recently brought in. It's the "if" statement in ZCML... Philipp _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
