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 configuration. 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? Chris _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
