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
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
> 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,
This message was sent using IMP, the Internet Messaging Program.
Zope3-dev mailing list