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 complexity. 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: http://www.nabble.com/yagni-on-overrides--tf3654999.html#a10211120 Sent from the Zope3 - dev mailing list archive at Nabble.com. _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com