Tres Seaver wrote:
>> 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
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).
> 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
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -