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 called. > 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 Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
