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

  - 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

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.


This message was sent using IMP, the Internet Messaging Program.
Zope3-dev mailing list

Reply via email to