Hey, Leonardo Rochael wrote: [snip]
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.
Regards, Martijn _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
