In the "Goals" section of my proposal
(, I state:

  Apart from the "elementary" directives (adapter and utility), ZCML
  directives are good for...

  * registering something that isn't a utility or adapter. E.g. setting
    a security policy, registering a TALES namespace adapter, global
    principals, registering a meta type/portal type in Zope 2/CMF.

  * registering an adapter or utility with added policy information that
    belongs in configuration, not in code. E.g.:

    o security information (e.g. view, browser:page in addition to
      adapter, the content/class directive)

    o 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)

  * additional ways of defining application policy. E.g. granting
    permissions on roles, etc.

This is my answer to "What is ZCML?".

ZCML stands on two pillars: registration and other application-related
policy. The third pillar, automation, is better done in Python. This is
another point in my proposal.

You're pondering about the meaning of "C" in ZCML. "C" is about the
first two pillars (registration and other policy), it's not about
automation. "Configuration" here doesn't necessarily refer to component
configuration (unless it's an SMTP hostname, etc.), but to the
configuration of the application as a whole. It may be that this view
has changed over the past 5 years, but that's perfectly fine! As Jim
said, everybody makes mistakes, that's how we learn.

It also seems that you see the creation of a "TiksLanguageVocabulary"
based on a general "LanguageVocabulary" as configuration. But it isn't.
It's merely the *creation* of a component. Only the registration is the
configuration, because that's what in the end changes application policy
(its existence in the utility registry).

Zope3-dev mailing list

Reply via email to