Martijn Faassen wrote: > > No. But I don't think that it'll be much of a problem. I expect that not a > > lot of 3rd party packages will need their own set of ZCML directives. > > Currently I know of five and union.cms doing it. I'm certainly > considering doing so for Silva. Then there's the example of many > packages in the Zope 3 core which are actually quite independent from > the core itself, such as the email package, and may in the future become > Zope extensions.
Here's what I think are valid reasons for having directives beyond the ones I call "elementary": * You need to register something that isn't a utility or adapter. The security policy comes in bind, but also a TALES namespace adapter or even global principals. CMF or Zope 2-specific directives for registering meta/portal types are also covered by this. * You need to register an elementary component but with added policy information that doesn't belong in code. This basically includes: - security information (that's why we have view, browser:page, etc.) in addition to the plain adapter directive, it also justifies the content/class directive. - configuration information for the component (e.g. SMTP host for the mailer utility, locales directory for the gettext message catalogs, text file for the help topic) * You need additional ways to define policy (e.g. granting permissions on roles, etc.) I think we can fit many existing directives minus the ones I'd like to get rid of in the other proposal into these three categories. That means I'm not questioning many more directives than the ones I'm talking about (incl. the ones at the bottom of the proposals). However, I *am* questioning the need for a lot of custom directives in 3rd party packages. Given the usecases for ZCML directives above, I don't see Silva or Plone themself bringing in new directives, but I could imagine a Silva-specific security policy would have some. Or a Plone-specific Cache manager. That's perfectly ok with me, they need to define policy in addition to just being registered. Just note that I'm explicitly not addressing automation as a use case for custom ZCML directives. I believe automation is best done in Python. If you're trying to invent a new ZCML directive that does something else to an adapter/view/utility before registering it (e.g. putting an interface on it, adding attributes, wrapping it in a factory etc.), then that should be done in Python. zope.formlib is a good example of how browser:page is enough for registering a form as it isn't ZCML's concern *what* kind of page we're registering. All that is in Python. > I'd say adding a namespace is a common method for abstracting > application specific component configuration tasks. Not sure what you mean by these last five words :). I agree that namespaces are a good idea to avoid name clashes. I like how we use dotted names for permissions, factory names, etc. Just note that there seems to be somewhat of a consensus on how to use those (invent your own dotted name-prefix for your own package). Only *that* makes the namespace convention actually avoid name clashes. In ZCML we don't seem to have an understanding of what goes into which namespace. I'm trying to figure it out. 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
