Martin Aspeli wrote:
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).
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.
I think they might hold for the Zope 2/Zope 3 scenario. The package
author would supply a configuration set which configures everything,
including adapters. The package author would also supply a configuration
set which *doesn't* configure the adapters. This set is of course reused
by the former, which simply adds the adapters. Zope 2 code could then
use the the second set which doesn't register the adapters in the first
place.
Your second scenario is a bit too abstract to say much about it. In some
cases if you can get away with a single override, overrides might be
simpler and relatively easy to maintain. If you have to override a lot,
configuration sets seem like a better approach.
The great benefit of going for configuration sets is that they actually
record common override requirements in code instead of having to
reestablish them each time.
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 say maintaining configuration sets is *risky* as you might break
things in upgrades? Cumbersome, yes, I can see that, as people would
have multiple ZCML files to worry about instead of one. That said,
presumably you'd have bigger configuration sets reuse bits of the former
- they shouldn't be copies, which should at least reduce the
cumbersomeness somewhat.
But risky? I think the maintenance risk overall is reduced. An override
can easily break if something changes slightly in the overridden
package. If a set if maintained and there's a public configuration
contract a package fulfills, maintenance risk should be less.
You could have some kind of inheritance mechanism, of course. My set
extends your one.
Do I misunderstand you here, or are you referring to the ZCML include
directive?
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. :)
I think the difference is that some configuration knowledge is
maintained in the original package, instead of in each place that might
need an overrides.zcml. The difference is also that it becomes suddenly
possible to do what people want to accomplish with disabling bits of
ZCML. Instead of an override disabling another ZCML directive, that ZCML
directive is not included in the first place.
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.
I agree that a safety valve needs to remain. I also think that it would
be quite worthwhile to investigate ways to avoid the need for a safety
valve in so many cases. Overriding carry a significant maintenance risk:
you are overriding the configuration contract provided by another
package. You need to know details about how the other package is
configured to do it right. It can easily lead to an override breaking if
a package's configuration changes. It can also easily lead to an
disabling override not disabling enough, if you use an updated version
of the package. What for instance if I disable all browser registrations
in a package I depend on, then upgrade this dependency, and suddenly it
includes a new browser view?
Anyway, again, I do agree that this might all be somewhat cumbersome to
maintain. That would be less the case for Grok, as Grok would use tags
to identify configuration sets. tags are relatively easy to add - a line
of code per component, in some cases only a line of code per module. No
need to reorganize separate configuration files, which is a fairly rigid
way to define configuration sets anyway. If we make those tags be
interfaces, we suddenly have quite a bit of power in defining
configuration sets, and in selecting what configuration profile we want
when using a package's configuration. Lots of details to be worked out
first, though.
Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
