Leonardo Rochael wrote:
So, perhaps, we don't need powerful zcml overrides, just cooperative package
maintainers (of which we have plenty in this community).
Interesting to see some of my ideas for Grok make it back here. :) After
your mail I realize now that with ZCML you can do more or less what I
describe out of the box: you can simply supply multiple configuration
files per package and tell people which one to include in their own
package. That is definitely an interesting approach, so thanks for
pointing that out, Leonardo.
Note that I think overrides/selective disabling is still useful in
special use cases. It may be that you're in a hurry and just want to use
the package out of the box, it doesn't have the ZCML you want. Just
being able to disable or override little bits might be useful then.
Then again, I think you're arguing you should in that case simply copy
the ZCML from the given package and eventually donate back your
refactored version which does what you want. That makes sense.
In general, selective overrides and disabling tends to make more sense
if you want to use 99% of a package's ZCML and only want to override a
little bit to make progress. A form of grouping of different ZCML
configurations indeed would be nicer in the other cases.
I also think overrides might be of use if you use package A which uses
package B which uses package C, and you want to override something in
package *C*. Of course with clever refactoring of individual
configuration files in all three packages you could still pull that off,
but it'd take a lot of communication.
A nice aspect of grouping configurations as a response to the desire to
override/disable bits is that such groups can become part of the common
code base and evolve.
Zope3-dev mailing list