Best Practice: Separate App config from Framework Config
July 29 2008 by 
Adam
Best Practices is something that I don't think anyone, anywhere, ever gets 100% right. There's no "right" way to do everything. But we're striving to do things better all of the time, right?
For example, in the ColdFusion world we have Unit Testing frameworks like MxUnit, CFUnit, CFCUnit, and Selenium. I know Selenium isn't just for CF, but it does integrate nicely! Test-driven Development is all the rage these days, and while that's a good thing it's not for everyone and certainly something very difficult to "get right."
Consider that in a large project — one with 1,000 test cases — if you refactor some code that affects 10% of your tests, you have to re-write 100 test cases. This isn't to say that TDD is a bad thing… far from it! Just that there is no silver bullet, and that you always have to be thinking ahead to try and do things right the first time, and not repeat yourself.
This brings me to a change I recently made in Grub.
Grub uses the Model-Glue framework to, as I like to say, "code less and do more." In Model-Glue's XML config, we have an <include> tag that allows us to separate our config into logical sections to keep maintainability high. But did you know you can do the same thing with your ColdSpring XML config?
Well, not with out-of-the-box 1.0… You have to download the Bleeding Edge Release, here. The feature was first mentioned in November of 2006, when Jared announced that he had written it. It was then blogged by a bunch of other ColdSpring users, but I don't think any of them mentioned that it wasn't yet included in the official release except Mark Drew, and even then I don't think I picked up on that fact until well after my second or third reading of his post. I ended up reading this bug report that clued me in, after about an hour of trying to figure out why the necessary method wasn't where it should be.
After you download the BER and update your local copy of ColdSpring, you can add lines like the following to your beans XML:
<beans>
<import resource="ColdSpring_MGConfig.xml"/>
</beans>
I used this code to separate out my Model Glue config — which will be constant in every environment, but different between them (debug, reload, allow event generation in dev; no debug, no reloading, and no generation in production or staging) — from my bean definitions, which change frequently as I work on the applicaiton. Now, with my ANT build script, I can build and deploy my project without ever thinking about config, and I know it will always be right because it will never change without me doing so manually.
I'm somewhat surprised that over a year has gone by and it's still not included in the official release. This means that I'm currently using two unreleased frameworks in Grub (the other being the Model-Glue 3 RC), and that I am going to have to include them both in the download to make it as user-friendly as possible.
Posted in Best Practices | ColdFusion | Frameworks | 
5 comments
Jul 29, 2008 at 9:10 AM
Well, based on what we have learned you are 'on track' to figure out what a Framework is. Our COOP library works either as an Application Framework or the core in version 2 we are working on is portable as a (MVC) View Framework.
So... what in the world am I saying? There is a difference between a Site configuration and an application configuration. (Or there should be IMO.) There is also a difference between a Application Framework (which covers Model Glue, Machii, Fusebox, ColdBox and others) and the applications under the hood. I completely agree that these should be 'able' to be done in segments.
With that said, one other misconception is that you have to use a "XML" file to do the framework configuration for ColdSpring. You can actually load the config a number of ways if we read the docs so this is very approachable IMO. We just need to have a programmatic way to load all the needed config files. It might even be good to consider domain safe bean naming conventions so these things don't conflict with each other.
Jul 29, 2008 at 9:42 AM
Is there a reason that something like BeanFactory.loadBeansFromXmlFile(where BeanFactory is an instance of coldspring.beans.DefaultXMLBeanFactory) can't be used to accomplish the same thing? In our implementation, we break the configuration out into several logical groupings across multiple xml files, and then just loop over all files in a given configuration directory when initializing ColdSpring, which essentially gives us the same thing (assuming that I understood the point of your post).
Jul 29, 2008 at 11:29 AM
Part of the reason I am using XML to configure my ColdSpring beans is that it can be (and is, in my case) easily generated when I generate some code in Illudium. Why create more work for myself by doing it any other way?
As Rich points out, you can manually load your beans into ColdSpring, essentially accomplishing the same thing, only with more work. I was already using Model-Glue's <include> tag, so for consistency's sake I was curious if the same was available for CS. When I found Jared's blog post, it just seemed to make sense to me. A lot of it is personal preference, I think. My preference is that the "main" config file points to the others, so that someone coming behind me knows explicitly what's being pulled in, rather than inferring because all of the CS XML files are in the same directory. That doesn't mean I think the other ways are wrong, they just don't fit my style as well.
Certainly, do what works best for you. The important part is that you can easily build and deploy your project with as little intervention as possible; and part of that is separating application config from (As John points out, Application) framework config. :)
My point was more that the feature has been included in the Bleeding Edge Release now for over a year -- isn't it about time it was included in the official release?
Jul 29, 2008 at 12:12 PM
And some documentation! Eh? The docs are over due for an update.
Jul 30, 2008 at 9:13 AM
John,
Where I come from, if you suggest it, you're volunteering to spear-head it. I don't think Chris and the other CS team members would object to well written documentation being donated. :)