Stephan Richter wrote: >>As we have learned that we can reduce nearly all component tasks to >>adapters and utilities, many tasks revolving around registration and >>configuration of policy also only involve adapters and utilities. By using >>those "elementary" directives we can stimulate the learning process for >>developers ("there should only be one way of doing things"). Yes, you might >>have to use two or three directives instead of just one new one, but you'll >>know what you're doing... And you'll remember it in 2 months. I think >>that's more valuable than saving a couple of lines today. > > > I think this is the wrong thread. :-) We are discussing the one namespace > here. If I would be against replacing one special directive with a couple > fundamental directives, I would have voted -1 on the other proposal, which I > did not.
So, you agree that the number of ZCML directives should not grow too much, yet you say that you want to keep people adding new directives. That doesn't add up for me. >>That said, there might still be a small percentage of cases where custom >>directives are a valid tool. I can accept their being on the same namespace >>as others. In fact, I would like it to be that way, reducing the amount of >>dead chickens (namespace declarations). > > I do not think namespace declarations are dead chickens. Per se, they aren't dead chicken for me either. > For me declaring a > namespace in ZCML is the same as importing a package or module in Python. That's not quite what it is for me. Rather than a package-afiliation, namespaces currently seem to indicate usage (browser:view vs. xmlrpc:view). To use namespaces for this seems arbitrary. This is also along similar lines of the "The distinction which goes into what namespace is highly inconsistent" problem. Why would security-related stuff not have a 'security' namespace, but 'browser' stuff does? Philipp _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com