Am 29.04.2010, 13:32 Uhr, schrieb Chris Withers <>:

> So why the big warnings in the book?

They're not warnings but reasoned guidance and developer preference.  
External configuration à la ZCML was not invented by Zope. XML is verbose  
but good editor support makes things a lot easier.

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

Disabling configuration rather than removing seems to me an invitation for  
trouble. But you could probably add a disable directive. Can you provide a  
real world example?

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

Which is one of the reasons why declarative configuration has its place.

Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
Repoze-dev mailing list

Reply via email to