Tres Seaver wrote:
Hash: SHA1

Martijn Faassen wrote:
Tres Seaver wrote:
Wichert Akkerman wrote:
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.


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See

Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to