Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martijn Faassen wrote:
Tres Seaver wrote:
Wichert Akkerman wrote:
[snip]
So I turned things around: if I state in my egg information that I
require another package that means I need to have that package
available and functional. Which suggests that its zcml has to be loaded
before mine. And that is exactly what I am doing: adding an entry point
that allows a package to say "in order to function I need to have these
zcml files loaded".
I may not *want* the other package's ZCML to be loaded: some of its
policies may not be appropriate for my application.
Since this appears to be a rare case that is the exception, what about
using the new ZCML exclude framework for this case? You need to know
what you are doing, but this use case is for people who know exactly
what they're doing anyway, right?
It isn't that rare: how many people want to turn off the Rotterdam skin
in Z3, for instance? In general, the authors of a "library" package
can't anticipate how their code will be used; the ZCML they provide is
intended to cover the cases they know or imagine most people want.
That probably depends a bit on how that package is created though. In an
ideal world, Rotterdam would be a separate package (or packages) that
could be pulled in or not (i.e. if you don't depend on it and/or you
don't include its ZCML file and/or you use the zc.configure exclude
behaviour to turn it off).
ZCML represents policy, not mechanism, and hence is inherently less
reusable than code.
That is true, but how many people actually re-do all the ZCML for all
the packages they use? Most packages, I imagine, will have been built
with re-use in mind. They make appropriate use of adapters and marker
interfaces and whatever else so that the user of the package has some
control, or even an opt-out. But for most packages, I don't think
there's going to be a host of different policies that are actually
interesting.
Put differently, in Plone we choose not to include various packages, but
the ones we *do* use, we tend to use wholesale. We may override (or use
a more-specific adapter for) some policy decisions, e.g. when it was
written for zope 3 and we need some zope 2 magic, but up until now
that's tended to be pretty manageable.
I fully subscribe to the separation of policy and implementation (though
I think in practice, "policy" is often something you override with
specific adapters or utilities, not only expressed in ZCML), but I
really hope that most Zope 3 developers don't end up reading,
understanding and may reproducing every single line of ZCML in every
single package they ever depend on. :)
I think Jim's suggestion was good, though: Something like Plone or Grok
- that want to be "pluggable applications" - could use an
<includeEntryPoints /> type ZCML directive to process ZCML pulled in via
entry points. Other packages may choose not to do that. Other packages
again, may choose to do that but then use zc.configure to turn some
stuff off, or just override whatever registrations they need.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
_______________________________________________
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 )
