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.
> Simplistix - Content Management, Batch Processing & Python Consulting
> - http://www.simplistix.co.uk
> Repoze-dev mailing list
Thomas G. Willis
Repoze-dev mailing list