Leonardo Rochael wrote:
If someone else presents me with an alternative zcml configuration for my
package that was useful for their project, I can put this zcml file in my
package for others to include when using it, instead of my default
configuration. If there are parts in common between the default and
alternative configuration, I'll refactor both configurations to make use of
a common part (say, the browser cofiguration). Or maybe they're mostly the
same except for some unwanted part (say, the subscriptions), then I can pull
this part into a separate file that is included by my default configuration
along with the other, more commonly used part.
A few more iterations of these refactorings and soon enough my package will
have configuration subsets that should be useful for most users of my
package without requiring them to copy a significant amount of my
configuration, and without requiring them to override any part of it.
So, perhaps, we don't need powerful zcml overrides, just cooperative package
maintainers (of which we have plenty in this community).
That assumes that (a) there are meaningful "sets" of configuration
settings and (b) that where people want to override something, it's
likely others will need the same overrides.
I've seen two use cases for overrides.zcml:
- Zope 2 code needing to override Zope 3 adapters to do some Zope
2-specific stuff.
- Custom code that (i.e. for a specific project) that needs to change
the behaviour of some standard component.
In the two cases above, however, I'm not sure the assumptions hold.
Having 'configuration sets', if I understand you correctly, would mean
keeping two sets in sync even if they only deviate slightly. That'd be
cumbersome and risk dependency upgrades breaking things. Thus, it only
makes sense if there is a maintainer to look after it all. But even then
it would be cumbersome.
You could have some kind of inheritance mechanism, of course. My set
extends your one. That's not very different from an overrides.zcml,
though. I have two "sets of configurations by having two overrides.zcml
files and making sure only one is in use at any one time. :)
When we *predict* the need for things to be overridden, we tend to make
things overrideable e.g. with sensible interface modeling to allow a
"more specific interface" override for an adapter or view, say. It's the
unpredictable cases where overrides.zcml provides a useful safety valve.
Martin
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
