On 04/29/2010 07:32 AM, Chris Withers wrote:
> 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?

You won't.

> What happens if a scan finds two decorators for the same thing?

Each adds some configuration.  Neither cancels each other out.

>> 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?

For the reason I said at the end of my last email.  When you distribute 
an application that uses ZCML for its configuration, it is possible to 
recover from bad chunking pretty easily.

>> 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?

I dont know what other people generally do with ZCML.  I personally try 
to break it up into one logical set of registrations per file. You still 
can't unregister something via overrides.

>> 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
> configuration.

Zope has some add-on that lets you do this.  I don't remember what it's 

> 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 :-/

Yeah, that doesn't really work.  Which is why we have the other modes.

- C
Repoze-dev mailing list

Reply via email to