Carsten Senger wrote:
> zcml contains many useful informations and I often use it as
> documentation how things fit together. It would be a loss to detach all
> zcml from the implementations into one/few big zcml packages.
> Moving them into one dedicated zcml for every package leaves them
> logically related to the implementation.
> It's also easier to maintain:
> - The zcml for an implementation has the same release cycle as the
> - Every relevant change in an implementation would need changes by a
> number of "zcml package maintainers" (Grok, Zope2, Zope3ZMI) that
> don't know the package nearly as good as the package maintainer.
> I would prefer to find them inside the implementation packages where
> possible. Where it's intended to reduce dependencies a dedicated zcml
> package like zope.i18n_zcml is at least more clear.
You make good points in favor of keeping this information close
together. I'll note that with grok-style packages it's actually not
*possible* to remove the information out completely, as it's in the
Python code. You can choose not to configure this code at all, but
I think whether ZCML is useful depends, in part, on much on how much
ZCML a package defines today.
If a package defines a little bit of ZCML only, I think it's less of a
risk to pull it out.
If a package defines a *lot* of ZCML, we will have to wonder about the
purpose of the package (is this really a library-like package or more
like an application defining a UI or something?), and we'll have to
think about another strategy.
I want to move this discussion to concrete examples next and see what a
treatment of moving out ZCML would entail.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -