I was reading the discussion on overriding and disabling configurations here
and on grok-dev and I can't help but feel that enabling overrides and trying
to make them smarter or more powerful is the first step in a slippery slope
towards making zcml turing complete.

In grok-dev, Martijn (I think) was proposing using 'tags' in the grok
directives to group parts of the configuration process together so that
another package that depended on this one could enable different parts of
the configuration as desired, instead of being forced to enable all or none
of the "grokked" configuration (at least that's how I understood it).

This lead me to believe that having zcml overrides is perhaps an unnecessary

If I maintain a package with a set of wiring zcml directives, those that
want to use my code are free to include my configuration or not, in which
case they might have to repeat a large part of my zcml in their own code to
make use of the parts of my configuration that was useful for them.

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).
View this message in context: 
Sent from the Zope3 - dev mailing list archive at Nabble.com.

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to