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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Faassen wrote:
> 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).

The fork is not merely to reduce dependencies:  BFG also wants to
eliminate the requirement that there be "one global component registry
to rule them all," which is pretty deeply embedded in zope.component.
Breaking that assumption allows multiple BFG apps to run in the same
process, with incompatible components registered, without any chance
that they will step on each other's toes.

>> 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.

"Reusable configuration" is a bit of an oxymoron:  if everybody *must*
use the configuration, then it isn't configuration at all, but software.

I think, however, that this discussion is about where to put the "meta"
bits (the parts which actually implement ZCML directives), rather than
rehashing the library vs. application problem (where to put the
configuration).

>> 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.

I would argue that putting any ZCML-related implementation in a separate
package from the zope.component core would be a win, at least from the
perspective of clarity and dependencies.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJkE3v+gerLs4ltQ4RAvbxAJ40EfLHA+l/8ixXFmuVQJO9e15QYQCcDazx
rGxL8+ZQpfxnAPbGLV1O0GM=
=mutG
-----END PGP SIGNATURE-----