My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
There's been an ongoing discussion in the Coldfusion community for quite some time now regarding the use of XML for configuration files to your applications. More recently, Peter Bell has written quite a few posts about it in The Benefits of XML Config Files (and why I don't use them), Configuration Files vs. Scripts, and most recently, Should you use XML for you configuration files?

He references Hal Helms, Joe Rinehart (and thanks Jim Collins who wrote (or co-wrote?) config.cfc for these), and Martin Fowler.

This post was sort of "sparked" by Jim's release of config.cfc, then my ensuing question about "when and why" I would want to use it (and no, I didn't mean it to sound that provocative), and then Peter's response to which this post title is addressed as "regarding."

I'm a little late to the party, but I thought I'd chime in nevertheless.

First, I want to start off with my position that "there are no best practices, only better practices" (to quote my professor Venkat). And to paraphrase Peter, a lot of people who know a lot more than I do use XML configurations. On the other hand, a lot of people who know a lot more than me don't use them.

Second, I'd like to point out that I found it mildly funny (not in a bad way) in reading some of the reference documents that some of us consider XML to be human readable. I don't think you'd find that statement anywhere except the Coldfusion community.

Finally, now that I've got the mile-long introduction out of the way, let's continue.

In Hal Helms' article, he is touting the benefits of configuration files in general. He makes a convincing argument, and has motivated me to be a better job of extracting things I never thought would should be configurable, unless I was building something that needed to be internationalized. He compared the INI file to those of the XML variety, and mentions that "some configuration information is more complex and is a poor fit for the simple nature of the INI file. In such cases, XML can be the ideal solution." I think it would be hard to have a problem with that statement, especially given the context of the article.

Joe Rinehart also only touches on the topic - he says that XML "provides the easiest way for us to partition off our configuration into logical 'chunks,'" and doesn't go into detail beyond that (for explaining why XML is a Good Thing.

But, Peter goes into a lot more detail about the benefits of XML. In particular, he mentions (Peter, if you feel I've reproduced too much of your article here, let me know and I'll trim it down)
As long as you have a DTD/Schema for your XML, you can validate XML against the DTD/Schema to confirm that it meets the specificed requirements. This can be extremely useful in pre-checking your data before getting a ColdFusion error because your configuration data was not well formed. Better yet, you don’t need to write any of the validation code – just the DTD/schema.

With XSLT you can transform XML files from one structure to another and you can even query the data using XPath. There are lots of great tools for working with XML files and again, they’re just there. You don’t need to write them.

There are plenty of good free plug ins for Eclipse and stand alone editors (XMLBuddy seems to be a popular Eclipse plug in). People are mostly used to editing in XML and there are good tools with highlighting and that will validate against a DTD/Schema in editor.

As in Steve Krug's "Don't Make me think", framework design choices should bear in mind that many people spend most of their time using something other than your framework. I may not use MG often, but apart from learning the vocabulary of the DSLs, there is no real learning curve in terms of how to create an XML config file for Reactor, CS or MG. Same for Mach-II and anything else that uses XML configuration files. It is usually better to do things the way people expect so they have less to learn.
Like Peter, I find XML to have a low signal to noise ratio (in "Benefits of XML Config Files...", though he said "high," if he'll allow me to put words in his mouth, I think he meant low).

I should also put a bit of a disclaimer here: I've spent the last three months working on a Java project, so I'm sick of XML configuration. And in general, I've only rarely used XML configuration files with Colfusion, and even then in fairly distant past. In that regard, let me profess some ignorance, especially regarding DTDs. Lately, I've been preferring programmatic configs (written directly in CFML/script). However, I've also not been needing much in the way of configuration, so that may help blind me to the benefits of XML. In any case, let me get into some reasons as to why, comparing that with the perceived benefits of XML.

Validation: As opposed to validating my XML file with a DTD/Schema, I validate my code with unit tests. These can similarly be provided to other programmers to validate their configurations. Now, I don't know how in depth validation can go, but it seems to me I'll be writing some validation in CF even if I use XML, and if it wasn't well formed, or did not meet my expectations, the unit tests would catch that. Another thing frequently mentioned is that it would be better to catch any errors in the spot the error occurred. I agree with this, but if you are validating your programmatic config file (with unit tests or otherwise), it is easy enough to throw an exception in that one spot, rather than letting the error propagate through your code.

Manipulation: I don't suppose I can use a converter to change my programmatic config file, but I'm not sure I see a reason to either. If I chose to, I could query the data with SQL using a query of query, as opposed to XPath.

Editing: I feel it is as simple to edit CFML as it is XML, so I don't see a benefit here, except the highlighting he mentions. But, if we're writing CFML, it is easy enough to check for syntax errors, and if you're using a decent editor, it will also highlight syntax errors for you. I realize it won't highlight "syntactic" errors by missing out on something you need in the config, but I don't value that highly, since I cannot remember a time I wrote a config file from scratch, unless I was creating the application (and in that case, the XML highlighting is unlikely to help you).

Consistency: As he mentions, there is little to learn in how to configure different apps when they use similar XML. But, assuming the person configuring the XML file is also the programmer, the part you have to learn is precisely the part you need to learn in a programmatic configuration file! You don't need to relearn how to do <cfset name = value>, you need to learn what valid names and values are. In the case that the person configuring the application is not a programmer, I'd almost certainly have provided a GUI frontend to the config file, or likely stored it in a database in the first place.

Finally, Peter mentioned that although just a few variables don't need XML, you might need it when configuring 200 beans for ColdSpring or LightWire (both dependecy injection frameworks). I have a hard time seeing that something which is weighty for a small project could be anything less than unwieldy for a larger one. Especially in this example, if I was using something that required an XML configuration file, I would undoubtedly store the information for all those beans in a database, and write a script that would write my XML file for me.

Overall, I like what Martin Fowler said the best: "I often think that people are over-eager to define configuration files. Often a programming language makes a straightforward and powerful configuration mechanism... My advice here is to always provide a way to do all configuration easily with a programmatic interface, and then treat a separate configuration file as an optional feature."

So having said all that, if and when I find a good case for using an XML configuration file, I'll gladly do so, and so should you. Nor should we discount XML - as Peter said and I agree, a lot of really smart people use it. But at the moment, I don't see a need for the excess clutter in my life - CFML provides enough of that for me =).

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

Leave a comment

There are no comments for this entry yet.

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)


Subcribe to this comment thread
Remember my details

Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner