Configuration is Code: Presented on Grails Spring Bean Builder (a.k.a. Groovy Spring Builder)

Last night, I presented at Groovy.MN on the Grails Spring Bean Builder, which is actually independent of the larger Grails project. It’s a nifty way to build Spring ApplicationContext using the Groovy Builder pattern instead of XML.

I’m a big fan of Spring, because the reality of most applications is that they have a lot of parts that need to be mixed-and-matched based on the environment. However, the XML configuration file always made me kinda cranky, because it was complicated enough to need an IDE to help you out (otherwise, you had death-by-typos). It also made me nervous, because it made people think that somehow configuration wasn’t code. This leads to conversations like this one:
Random Person: This XML-based rules engine is awesome!
Me: Rules engine? Blech.
Random Person: Why don’t you like rules engines?
Me: They’re complicated, and they don’t really gain you anything.
Random Person: But they let you configure the way your program behaves outside of code.
Me: Define “code”.
Random Person: Things that you compile.
Me: If compiling the code is the problem, then the answer is Perl.

Your configuration is code. It changes the behavior of your application, it has to respond to its environment, and it’s only understood by the technicians working on it (at best). That’s code. The fact that you’re coding in XML is irrelevant (although I thought we discovered that sucked and moved past it a while back).

You can check out the source code for the presentation (literally or figuratively) here.

Related posts:

1. Eclipse and the Automagical Final
2. My Groovy-on-Grails Experience
3. Some final Patterns
4. Yet Another Reason final is Your Friend
5. Review: The DaVinci Code and Holy Blood, Holy Grail