Chris McDonough wrote:
> No.  You can always override an individual registration (obtained via 
> imperative configuration, a scan, or via ZCML) with a subsequent 
> imperative registration.  

Okay, but how would I override a decorator with another decorator?
What happens if a scan finds two decorators for the same thing?

> But at the end of the day, it kinda doesn't matter.  The framework just 
> provides mechanism; it's really the application developer's 
> responsibility to chunk things appropriately so they can be reused, 
> extended, or omitted.  

So why the big warnings in the book?

> A poor developer can make that hard even if he 
> uses ZCML as a registration mechanism: he might put all of the 
> registrations in a single ZCML file so that someone who wants to take 
> only some of the registrations must effectively take all of them or none 
> of them.  

Isn't that what people generally do with zcml and why zcml's overrides 
ability exists?

> Obviously something similar could also be done with decorators (just 
> comment out the "scan" and either do imperative config or ZCML in its 
> place).  But with ZCML you can usually just cut, paste, and change.  If 
> ZCML was not in the picture, you're often probably going to need to 
> think about converting decorator based registrations into imperative 
> analogues or ZCML instead of cut-paste-change.

It's something that's always bugged me and neither zcml nor anything 
else I've seen allow; the idea of turning off an existing piece of 

Decorators are a little harder 'cos you can't safely rely on the "last 
one wins" philosophy so you end up needing some kind of ordering, or 
raising an exception if "something" is defined more than once, which 
precludes one package customising stuff from another if they both use 
decorators - which is what I'm ideally aiming for :-/

What ideas do people have in these areas?


Repoze-dev mailing list

Reply via email to