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?

Zope3-dev mailing list

Reply via email to