On 04/28/2010 03:07 PM, Chris Withers wrote: > Hi All, > > In the BFG book their are copious references to the fact that using > imperative configuration (or the decorators, my preferred choice) is > "bad" if you plan to write apps that might be extended by others. > > Am I right in understanding that this is because that method of > configuration somehow prevents overrides being applied later?
No. You can always override an individual registration (obtained via imperative configuration, a scan, or via ZCML) with a subsequent imperative registration. You can even call load_zcml twice with two different files; the second time it runs it will override the registrations done during the first run. But usually you can't unregister something; there's no API for unregistration of views, for example. 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. 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. In the meantime, another developer might succeed when he tells folks reuse his decorator-configured application by documenting how to add individual registrations imperatively. In my mind, using ZCML for frameworky apps that you distribute widely (to people you don't know and may never know) has one advantage: it's slightly easier to recover from poorly chunked registrations when they're all done via ZCML. This is because the very worst case scenario is that the integrator doesn't bother trying to reuse *any* ZCML from the package he's trying to reuse and he just duplicates all of the registrations in a separate set of ZCML files somewhere else in the integration. 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. - C _______________________________________________ Repoze-dev mailing list Repozeemail@example.com http://lists.repoze.org/listinfo/repoze-dev