Lennart Regebro wrote: > I don't think it's about saving lines, but about saving headaches. ;-)
Having to remember how all of the mentioned directives work *does* give me a headache. I actually remember quite well how the utility and interface directives work and they are the replacement for most of the directives to be deprecated. I assume most people are like me in that respect, at least that's the assumption this proposal is based on. > > > I think that goal is misguided, as > > > it would require you to make longet ZCML files with more basic > > > statements. This in turns means you need to understand more of what > > > you are actually doing. > > > > Well, how much longer would the ZCML files really be? > > The point is that it requires you to understand more of the internals > of Zope3, making it even harder to use and understand. Which is > exactly the opposite of what people who try to use Zope 3 say they > want. What internals? That a factory is a utility? Well, people have to know that anyways when they want to look-up a factory. Sorry for nailing it down to that specific example again, I could say the same about vocabularies or whatever it is those directives are about. > And when it comes to step by step, I think we should think about the > big/basic stuff first, becuase that's what will cause problems if we > do it. Then you do it :). I volunteered for this task and I have to do it as I have time thinking about stuff. Right now I don't have much time but I still want to get somewhere. If that approach isn't in-line with the community, then I can't contribute at this point. That aside, I think even though this is just the beginning it'll make a big difference. Since I started documenting Zope 3 on a professional basis, I look at everything with "And how will I explain this to my reader?" in the back of my mind... When this proposal is through, I can simplify *a lot* in my book. > Depracating specific statements is comparatively a no-brainer. Good. I guess then we can drop this discussion and just do it :). > > The adapter statement is still necessary as an on/off switch. Who says > > that you > > always want that adapter? And perhaps you want to override it with a > > different > > one. ZCML is good for on/off switches, Python isn't. > > That's a good point. But maybe then it should be made into an > on-off-switch, instead of a defining switch? Perhaps. This isn't the scope of my proposal though :). > > I hope zope.app will go away :). Seriously, I rather have meaningful > > interfaces > > with which I register *and* look-up stuff the same way than registering > > something with a factory directive and looking it up by IFactory. I see no > > connection obvious connection there. And you will have to remember the > > interface anyway, whether you use <factory /> or not... > > As noted, I don't have any quarrel with removing the factory > statement. In fact, I think it is highly obscure, and personally, I > don't understand what you are supposed to do with it, which is a bad > indication. Indeed. > If you want +/- per statement, then I'm minus on removing > browser:addform, This isn't part of the actual proposal but just some random thought. However, there will be a proposal in the future that'll deal with the form stuff, and if it's only about getting rid of zope.app.form ;). > and I'm unsure about the vocabulary statements. (But > I actually want to get rid och schemas altogether, I think they are > complicated to use and understand and not good enough, and should be > replaced with something based on XForms. ). > > The others I'm either +1 on, or don't know anything about. Great :). Thanks for your input! Philipp ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com