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

[Martijn Faassen]

Hanno Schlichting wrote:
[snip]
>> Anything you'd actually be +1 on? :)
> 
> I haven't figured out yet, what I'd like to do with ZCML and
> zope.configuration in general. It seems to me that ZCML is right now too
> tightly bound to application configuration. Zope2 and Five need
> different action handlers and this will continue to be the case for the
> next years and possibly forever.

I thought significant process was made on the ability to reuse more 
handlers now that Zope 2 has got __parent__ support. Not enough?

> Grok has different needs for the
> configuration part of your application. 

Grok does reuse some actions defined for the use of ZCML actually, 
though sometimes we do introduce new ones.

> repoze.bfg takes yet another approach.

I'm sure there are new ZCML directives it introduces, but it also forked 
the current ZCML directives that are in zope.component for basic 
component registration, to reduce its dependencies. Perhaps that fork 
can be undone if we improve the way we break things down (to anticipate 
what you're saying below).

> Once we define a Grok-like API for Plone we will probably end
> up with yet some other kind of different semantics.

If you define altogether new actions that are Plone specific there might 
not be too big of a problem in overlap there.

> My gut feeling is that the best long term answer would be to figure out
> how to split zope.configuration and ZCML kind of in the middle. What
> parts of application configuration are actually reusable and which are
> not. How does application configuration and system configuration like
> paste.ini and zope.conf fir together?
> 
> Just trying to push out ZCML in itself seems better than having it stay
> in, but not what I'd consider to be a good long term answer.

I'd consider it at least a necessary step towards a long term answer, so 
you should be +1 for step one. :)

Another step would be to start taking a look at refactoring the actions 
to increase reuse. I think refactoring the actions can be driven by the 
needs of the code that uses it. If Zope 2 developers say: hey, we could 
*almost* use this action if it only didn't do this, we could use that to 
split the action into two parts so that the main part can be reused. The 
Grok developers and Repoze developers should look for similar 
opportunities.

It might be that some actions very similar to the ones the repoze fork 
now uses will make it back into zope.component, but that the extended 
ones that Zope 3 requires should be extracted.

Note that I don't mind much that zope.configuration has intrinsic 
support for ZCML (besides the general action-based configuration 
system). Grok needs that support anyway, and so will any system that at 
least wants to support packages that load their configuration using ZCML.

Regards,

Martijn