[Zope-dev] Dependencies for ZCML

[Martijn Faassen]

Hey,

Tres Seaver wrote:
[snip]
>> Doesn't that in some cases make tests harder to understand, as 
>> lower-level APIs are in use that are not as recognizable as the 
>> equivalent ZCML directives? (say, registering an event) Don't we place a 
>> burden on the test writers to learn these APIs while they could use the 
>> ones abstracted away behind ZCML instead?
> 
> No.  Relying on "real" ZCML in testing, as is using the "real"
> components is an anti-pattern:  it makes tests fragile, couples the
> packages tightly, etc.

Huh? You can't be serious saying there is not extra burden on the test 
developers if you require them to learn about the implementation of 
various ZCML directives in order to write a test. The burden is in 
learning how a view is registered, or how a subscriber is registered, in 
order to write a test. You need them to break through the abstraction 
that ZCML provides in order to write a test. It will also make it harder 
to read the tests as the reader will need to share this understanding as 
well.

You can't just go and say it's an anti-pattern without giving an 
alternative, otherwise people will continue to use the higher-level of 
abstraction for registration (i.e. ZCML).

[snip]
> I don't think "library" packages have ZCML in them at all, except as
> examples, because trying to reusing ZCML doesn't actually win
> unambiguosly over copying it.

Here's my position on this:

You take a hard-line purist opinion. We may want to take an attitude 
like this for the Zope Framework libraries, eventually. We cannot just 
do this by throwing out all ZCML from our packages.

Why not? Because the Zope community is in the business of providing an 
integrated experience too (Zope 2, Zope 3 and Grok), like it or not. 
(hold on, I know you don't care about this. I'm getting to this)

This means that we, as a community on zope-dev care about configuration 
(no matter where it is maintained). Since we do, we should maintain and 
test it. Since we're a community and care about compatibility it's good 
to share the burden of maintaining and distributing this configuration, 
instead of just ignoring this and deferring it to the individual projects.

Today, the "shared configuration" project is scattered over the 
individual packages in individual zcml files that refer to each other. 
If we want this project elsewhere, we need to take realistic, active 
evolutionary steps to get there, package by package. We can't just drop 
the ball on this, as we have projects depending on this information.

I know you don't care one bit about such projects yourself. You just 
care about the libraries.

Fine, but you'll have to acknowledge that other people *do* care about 
this project. They have frameworks and applications to maintain that 
need the configuration scattered through the Zope Framework code base 
right now.

I've heard your purist opinions in this area before. It's not very 
helpful in the way presented. If you want us to buy into your opinions 
you'll have to make them more attractive to us, and you know about our 
concerns as a community.

Regards,

Martijn