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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )