My One Wish for ColdFusion
I’ve read the recent flurry of blog entries about wishlists for ColdFusion 8. (As have many people, given the popularity of the subject.)
Personally, I only have one real wish for ColdFusion 8:
I wish that Adobe would allow me to configure an application without ever having to log into the administration interface.
What does this mean? Well, for example, it annoys me that I need to have access to the administration interface to create any data sources and scheduled processes I might need for an application. This includes caching configuration, mail server configuration, event gateway configuration (that’s the main reason I don’t use event gateways) and so on.
I believe that an application’s configuration should be separate from the server configuration. In particular, it drives me nuts when I have to use absolute paths for configuration settings! Relative paths could save so many headaches!
My reasons for this belief can be summed up as:
An application’s configuration is specific to an application, not to a server.
For example, two different applications rarely share the same database. Obviously these two applications need different DSNs. Why should this information be set at the server level? In my opinion it shouldn’t. The same thing goes for scheduled processes, caching, etc.
To deploy a new I should not need to access an unrelated administrative interface for the server.
This is particularly relevant to shared hosting providers, or any company which restricts access to the administrative tools. This not only creates a barrier that developers must overcome, but it opens the door to errors when deploying applications.
For example, if all of the data sources, scheduled processes, etc, were configured in an XML file, I could easily write an Ant script to deploy the application and make any configuration changes I need for production. I could easily, turn off debugging, turning on trusted caching, changing the mail server to a real server, and so on.
In a nutshell what is currently a manual process could be automated.
I shouldn’t have to remember the configuration settings for each site. Half the time I forget to do something like configure a scheduled process
Because I have to manually remember to make configuration changes as I deploy an application I’m likely to forget a step. If this is something like a scheduled process that runs weekly, it could be quite a while before I realize my application is broken.
I shouldn’t have to share the server’s configuration between applications
This is the last real problem I have with server-based configuration as opposed to application based configuration. What if on one server instance, I want to enabled trusted caching for one application but not for another? Simply put, I can’t. I believe configuration choices like these should be made at an application level.
I propose that…
First off, the administration interface (and its API) remain unchanged. I do think that this should continue to allow developers and administrators to add data sources, and make configuration changes at the server level.
Additionally, I would like to see an XML file or another configuration format which can easily be manipulated programmatically be used to override the server settings for a specific application.
For example, maybe Adobe would create a .cfn file which could contain xml markup. When the application starts up it would look for a .cfn file in the root of the webserver and parse it to find out how that application’s configuration overrides the server’s configuration. For example, it might create a data source named “Foo” pointing to the MSSQL database “Bar”.
It might also define a scheduled process which executes the file at “/foo/bar.cfm” every four hours. Note that this is a relative URL and is therefore independent of the URL the site may be accessed on. This would allow for the exact same configuration settings for this process between two development, staging and production servers. Less moving parts means less room for screw-ups.
All in all, I think that configuration is a part of an application, not a server. A separate configuration file becomes part of the application’s source code would be very valuable. It would make deploying applications easier and it would help reduce accidental errors resulting from configuration mistakes. Lastly, it would allow for automated deployments of applications.