[Zope-dev] ZCML implementations: where should they go

[Martijn Faassen]

Hey,

So the general idea would be to remove the complication extras
introduce in reasoning about packages. Extras can be removed in two
ways:

* carefully restructure dependency relationships between packages so
that extras are no longer needed (typically for test extras this can
be done)

* extract the code that is causing the extra and move it, either into
an existing package or into a new one. zope.component is a prime
candidate for this treatement.

At most, zope.component should provide implementations of configuration
actions that do not involve extra dependencies like zope.security. The
actual implementation of the directives can then reuse these core
actions and add the extra registrations they need.

I think there's good evidence that zope.component shouldn't be
providing the implementations directly:

* repoze.zcml - reimplements the directives sans security and with
concern for multiple registries

* grokcore.component - reimplements the functionality of these actions
but not reusing the action code, simply using provideAdapter and
provideUtility as underlying actions.

So, zope.component is both doing too much and not pulling its weight
in helping with configuration, as we have two packages that entirely
go around its configuration implementations right now.

I think we should study repoze.zcml and see whether we cannot fold
part of that implementation into zope.component as actions that can be
reused by both repoze.zcml as well as grokcore.component. We can then
move the implementations of the standard security-conscious actions
from zope.component, perhaps into zope.security (as that's really what
the extra dependency is all about, and the extra bit that gets added
to the standard directives is security-support), or perhaps into a
newly created package.

I suspect that if we create a new ZCML only packages we'd get very far
with something that would replace the ZCML defined in zope.component
and zope.security both, and with another package that tackles various
browser oriented directives. We're not looking at vastly expanding the
amount of packages.

Regards,

Martijn