Martijn Faassen wrote: > Prefixing 'browser' directives in the tag names to me is a big warning > bell that you really do want to use different namespaces. Another > example of the namespace mechanism working is that some people are using > it in their projects, adding namespaces specific to their project. It'd > feel ugly to me if I had to insert my own configuration directives into > Zope's.
Perhaps it is ugly, yet other well-known and widely used systems let extensions create new configuration directives w/o a need for a namespace. The Apache HTTP server is an example, ZConfig another one. It seems from an aesthetic point of view, many people would like to use namespaces. It's interesting that I got +1 comments back then and not today. Perhaps the reality of the proposal looked different than what people expected. Then it's still a good thing having discussed this matter. Especially because I'm still not convinced that we really understand what ZCML namespaces mean to us (see below). > Finally, a general use of programming should be to use the language's > namespace directive instead of prefixes, if the language does offer an > effective namespace directive. > > So, please don't try to fix this now. Work on reducing the complexity of > existing directives first, and work on deprecating directives. Then > reconsider this one. That is a valid concern. I too get the feeling that it might be a bit too early for this. I regard(ed) the two proposals I brought in yesterday as orthogonal to each other, but perhaps they share more causality than I would like them to. > Perhaps after this other step, matters will be clearer. I suspect quite > a few of the directives that can go away are in the 'small' namespaces, > such as mail. We may also want to move some directives to other > namespaces. If all directives disappear from a namespace, so can the > namespace. The potential for win can be much larger while the potential > for breakage is much smaller, as we can do this step by step. I agree. As we do that, we should also try to figure out when and how we decide what goes into its own namespace and what doesn't. Currently ZCML namespaces are used to: * Differentiate between different view types (generic vs. browser vs. xmlrpc) * Mark the domain of a certain registration (i18n, mail, rdb, help) * Associate directives with a certain, perhaps optional package (apidoc, other 3rd party packages) Why does apidoc have its own namespace and, say, zope.app.securitypolicy doesn't? Or why did zope.viewlet not put its directives into the 'viewlet' namespace but into the 'browser' namespace? All that seems arbitrary to me. Just as the fact that I'm "supposed" to put my frobnatz directive into the plone namespace even if a frobnatz is actually a browser thing. > I really think that the discussion on namespaces is so common not > because it's so important, but because it's an easy thing to comment on > and talk about. People are less likely to have huge discussions about > larger but harder to understand issues. Perhaps. But it also seems like they're talking about it because it bugs them a lot. Tres seems to think that we shouldn't worry about those "trolls". I'm inclined to think that if people have issues with ZCML and welcome simplifications, we should consider coming up with some. So far I'm the only one who has made constructive suggestions for doing so beyond Jim's adapts() hook (I won't count suggestions that seek to replace ZCML with ZConfig, YAML, etc.). 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