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)
Validation
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.
Manipulation
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.
Editing
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.
Consistency
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!
