[Zope-dev] Dependencies for ZCML
Tres Seaver
tseaver at palladion.com
Mon Mar 16 12:57:18 EDT 2009
-----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 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
iD8DBQFJvoTu+gerLs4ltQ4RAv9MAJ94Tl2cMkOsClBJ5aCnPI/rvwrN6wCg2QZD
BGuGDkLMp70Z9/j8JqhYcyI=
=f9LF
-----END PGP SIGNATURE-----
More information about the Zope-Dev
mailing list