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
>     implementation.
>   - 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 
that's it.

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 - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to