Details

The following lists outlines solutions for avoiding the deprecated directives in the future.

factory

This is just a shortcut to the utility directive and saves one line in ZCML (for specifying the additional IFactory? interface) and two lines in Python (for the title and description of the factory). For example:

<factory
    id="alias.SydneyBristow"
    component=".alias.sydneyFactory"
    title="Agent Sydney Bristow"
    description="Sydney is an undercover agent working for the CIA"
    />

would become:

<utility
    provides="zope.component.interfaces.IFactory"
    component=".alias.sydneyFactory"
    name="alias.SydneyBristow"
    />

whereas title and description now have to be specified as regular attributes on the factory component. Note that these values should generally be i18n messages because they might appear in browser menus.

vocabulary

Despite its name, this directive doesn't register vocabularies but vocabulary factories (because vocabularies are content dependent and might need to be initialized with more than just the context). It is probably one of the most magical ZCML directives of all.

First, it is the only directive to take arbitrary arguments and by this it defies one of the initial aspects of ZCML (which is being restricted to a certain set of directives and parameters). Second, it creates a magical wrapper around vocabularies so that we can register them as vocabulary factories. All of this isn't needed at all, people can deal with these things much better in Python code, e.g.:

class SD6Vocabulary(object):
    zope.interface.implements(IVocabulary)
    zope.interface.classProvides(IVocabularyFactory)
    # the existence of this method satisfies IVocabularyFactory
    def __init__(self, context):
        ...

Now, this class simply gets registered as a utility providing IVocabularyFactory?:

<utility
   component="alias.SD6Vocabulary"
   provides="zope.app.schema.vocabulary.IVocabularyFactory"
   name="alias.SD6"
   />

instead of:

<vocabulary
   factory="alias.SD6Vocabulary"
   name="alias.SD6"
   />

Note that this will get rid of a (rather confusing) feature that involves the reuse of vocabulary implementations. A common type of vocabulary is the utility vocabuluary. A custom vocabulary listing a certain type of utility is easily registered with:

<vocabulary
    name="SD6 Agents"
    factory="zope.app.component.vocabulary.UtilityVocabulary"
    interface="alias.interfaces.ISD6Agent"
    />

Note that interface is an arbitrary argument here and is passed as a unicode string to the UtilityVocabulary? constructor. To achieve the same thing without the vocabulary directive, one would have to create a class in Python:

class SD6AgentsVocabulary(UtilityVocabulary):
    classImplements(IVocabularyFactory)
    interface = alias.interfaces.ISD6Agent

and register this in ZCML with the utility directive as shown above. This proposal argues that this is much more straightforward and better documentable than the current behaviour.

modulealias

This directive can put Python modules into sys.modules under a new alias, typically to preserve backward compatability for old pickles in ZODB. It is strongly questionable whether this has anything to do with registering and/or configuring components at all, let alone the fact that people like the author of this proposal feel a bit uncomfortable with putting something like that in ZCML in the first place. If a sys.modules hack is needed, it should be done in Python with a proper BBB comment.

Since the zope.modulealias package provides nothing else than this ZCML directive, the proposal calls for deprecating and removing the zope.modulealias package altogether.

renderer:renderer

Since the major simplification of the Component Architecture, this is probably one of the most useless directives of all times. It simply registers an adapter and does nothing else. Using the adapter directive here would not even cost you any extra lines. A search through the Zope 3 source code also indicates that it isn't used anymore.

rdb:provideConnection

This is just a shortcut to the utility directive and saves you exactly one line of ZCML. E.g.:

<rdb:provideConnection
    name="alias.UplinkToMarshal"
    connection="alias.marshal.uplinkConnection"
    />

would become:

<utility
    component="alias.marshal.uplinkConnection"
    provides="zope.app.rdb.interfaces import IZopeDatabaseAdapter"
    name="alias.UplinkToMarshal"
    />

dav:provideInterface

This is just a shortcut to a call to the interface directive (with an appropriate type argument) and saves only a few lines in ZCML. For example:

<dav:provideInterface
    for="http://purl.org/dc/1.1"
    interface="zope.app.dublincore.interfaces.IZopeDublinCore"
    />

would become:

<interface
    interface="zope.app.dublincore.interfaces.IZopeDublinCore"
    type="zope.app.dav.interfaces.IDAVNamespace"
    />


<utility
    provides="zope.app.dav.interfaces.IDAVNamespace"
    component="zope.app.dublincore.interfaces.IZopeDublinCore"
    name="http://purl.org/dc/1.1"
    />

While this might seem like a lot of extra lines that are needed now, one should remember that dav:provideInterface is rarely used. Zope 3 itself uses it twice and it is imaginable that custom DAV apps might use it once or twice as well. That is due to the fact that the number of DAV namespaces is rather limited, at least limited enough that a custom directive is hardly justified.

The WebDAVInterfacesWidgetsAndAdapters? proposal also proposed to get rid of this directive in the context of a refactoring of the DAV support.

browser:addview

This is a shortcut to the browser:view directive and would save one line in ZCML. Another problem with it is that it seems broken (by looking at its code). Plus, it is also untested and untested code is broken by definition.

This proposal therefore calls for its immediate removal (no deprecation period).

browser:localUtility

This is just a short-cut around the content directive and letting classes implement IAttributeAnnotatable? and ILocalUtility?. So it saves two lines of Python code.

Note that another proposal, Local Component Management Simplification is proposing to get rid of ILocalUtility?.

content and class

These are two names for the same directive which is confusing. Since this directive is mainly about making security assertions of any class, not only content components, it is proposed to remove the content alias and only leave class.

The following two items propose the removal of the two subdirectives to class that are not about security declarations. That way, the class complex-directive will be greatly simplified, only having two possible subdirectives dealing with security (require and allow).

class/factory

For the same reasons the factory directive is suggested to be removed, this subdirective of class is also proposed to be removed. It would better be served with appropriate statements in Python. E.g.:

<content class=".alias.Sydney">
  <factory
      id="alias.SydneyBristow"
      title="Agent Sydney Bristow"
      description="Sydney is an undercover agent working for the CIA"
      />
  ...
</content>

would become:

<class class=".alias.Sydney">
  ...
</class>

<utility
    component=".alias.sydneyFactory"
    provides="zope.component.interfaces.IFactory"
    name="alias.SydneyBristow"
    />

with .alias.SydneyFactory? being defined in Python:

from zope.component.factory import Factory
sydneyFactory = Factory(
    SydneyBristow,                     # a callable, e.g. a class
    title=(u'Agent Sydney Bristow'),
    description=(u'Sydney is an undercover agent working for the CIA')
    )

class/implements

This directive is often used to define policy by applying a marker interface to a class. The first problem with it is that you might want to use it independently from a class directive. Sometimes even (e.g. when in a 3rd party package), you would be conflicting with the class directive from the original package. Second, you might want to make factories other than a class implement something (e.g. a function).

This proposal therefore calls for the class/implements subdirective to be moved to its own top-level implements directive. E.g.:

<content class=".alias.Sydney">
  <implements
      interface="alias.interfaces.IHighestSecurityClearance"
      />
  ...
</content>

would become:

<class class=".alias.Sydney">
  ...
</class>

<implements
    factory=".alias.Sydney"
    interface="alias.interfaces.IHighestSecurityClearance"
    />

factory could be a class (in which case classImplements would be used) or any other object, e.g. a function (in which case implementer would be used).