-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote: > 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).
The alternative is that developers use 'zope.component.provide*' rather than loading ZCML. The upsides are: - - They can register stub implementations, some of which may not even be "importable" (e.g., local closures). - - They can avoid testing dependencies on 'zope.configuration' and friends. - - The tests run faster. - - The tests run "cleaner". > [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. Please don't put words in my mouth. I *do* care that the "mega-frameworks" succeed. However, I don't think that "blessing" the current usage is going to help them succeed in the long run. I think that moving the "shared configuration" bits out of "library" packages ought to be a fairly high-priority, near-term goal, in order to increase the quality / reusability of the "library" packages, which will also increase the quality / stability of the mega-frameworks, and reduce the burden of maintaining both. I think the tight coupling of "scattered + required" ZCML has turned out to be a net loss over time, because it forces people to make an "all-or-nothing" choice about adopting "Zope" early on in their evaluation. Making it attracive and easy to use pieces of Zope, while deferring that "all-in bet," is a big driver for the "purism" you are describing. > 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'll draw a semantic distinction, based on the grammatical ambiguity in that sentence: those applications "need the configuration", but they don't "need the configuration to be scattered through the code base", except for BBB purposes. For instance, if we provided for each mega-framework a single "everything {Grok,Zope2,Zope3ZMI} needs from the Zope framework" package, which named all the appropriate dependencies *and* provided the "shared" ZCML, and then switched each mega-framework and its applications to use that package, we could remove the ZCML from all the other packages (except for BBB). In fact that single package would *be* the mega-framework at that point. Once we had such packages, we could look at whether factoring out some of the common dependencies / ZCML from each of them into one or more shared "Zope Framework ZCML" package would be worthwhile. The choice to do such a refactoring would be transparent to existing applications built on the mega-frameworks. New applications might choose to target one or more of the "subset" packages, or not. > 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. Hmm, I'm not sure how to reply to that. I'll keep trying to clarify my positions, including removing any unintended "heat", and supplying any extra considerations to address your concerns. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tsea...@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 iD8DBQFJvoTu+gerLs4ltQ4RAv9MAJ94Tl2cMkOsClBJ5aCnPI/rvwrN6wCg2QZD BGuGDkLMp70Z9/j8JqhYcyI= =f9LF -----END PGP SIGNATURE----- _______________________________________________ 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 )