Some thoughts on Application Configuration

I've checked in some code into the BlogCFC 6 repo. Don't consider any code there as final code. Anything this early on is (most likely) temporary. While my main focus is on theming, there are some basic things I need to get out of the way. One of them is how the blog is configured at runtime. I've made some design decisions for v6 that I wanted to share (and get comments on).

1) In the past, you could have N blogs and one ORG folder. You configured the blog via the INI file. While this was handy, it separated your blog config from your blog install. I've moved to having config info in the same physical space as the blog client.

2) I switched from INI to XML. INI files had issues with non-latin chars. To be fair - it wasn't the INI file's fault, CF's functions to read them in. I never could them to correctly read in foreign chars. Even if I could - I'd move to XML anyway.

3) BlogCFC supports dynamic configuration. By that I mean you could configure it on the fly. I love this. It is what drives the blogs at RIAForge and other places. But to do so you edited Application.cfm. That's bad. What I'll be doing now is (most likely) simply including a file that is blank by default. This way you could edit the file for your settings and not worry about updates to Application.cfm in the core product.

4) If you look at the code I checked in, you will also see that I'm using the factory that Rob Gonda had made for Galleon. I plan on using this to help with the CFC creation. Why not ColdSpring? I'll say the same thing I say when folks ask why I don't use Model-Glue for BlogCFC. While I love MG, I prefer keeping BlogCFC as easy to install as possible, and with as few dependencies as possible.