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 

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 

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

Reply via email to