Am 29.04.2010, 13:32 Uhr, schrieb Chris Withers <ch...@simplistix.co.uk>:
> 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 -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
