On Wed, Apr 28, 2010 at 3:07 PM, Chris Withers <ch...@simplistix.co.uk> 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? >
When I read that in the book, I figured it was a deliberate choice to do things that way. And it kind of makse sense to me. In any application there is stuff that is critical to how your app works and then there is stuff that you expose as being configurable by someone else. If there is to be stuff that is configurable, it's handy to expose that in a common way as to communicate to the extender that this is what you anticipated and potentially took care to make sure it would work by placing that which can be configured in a standard/explicit place like say a zcml file. That way the extender does not have to surf your code to try and figure out what they can safely override and expect the app to still work, though they may want to surf the code and demolish everything. Just like the prefixing attributes that should be touched with a "_" to communicate that that attribute is somehow critical to the implementation and should be left alone unless you know what you are doing and are willing to accept the consequences. > If so, what can we do to change that? I've grown quite allergic to ZCML > in the few years since I last had to touch it... > I can understand the allergic reaction to zcml, hell I deal with over engineered java apps all day with version controlled xml "config files" they suck I would argue they've gone overboard with the configurability to a fault. At least BFG gives you a choice in the convention which in my mind makes zcml a little easier to swallow. my .02 > cheers, > > Chris > > -- > Simplistix - Content Management, Batch Processing & Python Consulting > - http://www.simplistix.co.uk > _______________________________________________ > Repoze-dev mailing list > Repoze-dev@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev > -- Thomas G. Willis _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
