When you have to bugfix, extend or review a ColdFusion application, there’s a good chance that you’ll find yourself browsing a directory tree representing the navigation on the site. Within these directories, typically some 40 or 50 files with names like list.cfm, insertform.cfm, insertaction.cfm, etc. reside.
You know you’re going to be in trouble, because as so often happens, your customer does not know exactly what he wants, or where he wants it. And now he wants this specific part of the site to reside in another part of the site, or more parts, … with security on it… and with some extra functionality, and… oh, we don’t have enough budget for more.
Without even taking a look at the code, you know you’re going to have to redo a lot of links (yes yes, they were linked dynamically, but the way it’s tied up together now it’s just not possible to make it work within the context of the new location on the site).
If you start feeling a little guilty at that point, knowing you used to write code like this too, and you’re worried about the mental state of the guy who needs to look into your code afterwards, for any reason, here’s a small tutorial for a fairly simple technique which I often use, and it does the job. It ain’t exactly Fusebox (which I can recommend to you all; this technique works fine as a fuse too), but it is proper coding and it gets the job done.
Let’s kick off.
The one and only thing I actually have to tell you is to create all your links like so:
-==-
What exactly do I mean by this?
Every hyperlink you create in this module posts to itself, keeping all URL variables intact. The ReplaceList carefully strips all the URL variables you wish to change, so that your next call to the module meets the settings you intend in this hyperlink.
The most important thing here is that pressing the hyperlink doesn’t affect any other code which may be executed outside of your module’s scope. Hence, we can plug the module anywhere.
Some Practical remarks:
We try to replace URL variables which may or may not exist.
Presetting these variables not only saves us from writing a lot of extra isdefined checks, but placing all these variables on top of the module gives us a quick and easy way to view all of the different behavours this module contains. We can get a good idea of what the module does, even without looking at the code, so as an example I ‘m going to preset some URL variables:
-==-
Why the mm_ ????
The mm is derived from the module’s name: MyModule. Imagine we place this module next to another module which also contains an “action” variable, I don’t want the modules to affect each other’s variable settings, so by preceeding the variable name with an abbreviation of the module’s name, there is a good chance the modules will not conflict.
The code I pasted below is a sample module in which I try to show in code what I explained above. The code is not tested; I just wrote it top-to-bottom, but you will get the picture. I ‘m convinced you learn more from a sample piece of code that may throw an occasional error (so you have to investigate the code), rather than just plugging in working sample code and changing some static text without looking at how it really works.
-==-
First published at developer.be
Certified Advanced ColdFusion 5 Developer
Focus on: coldfusion, content management / spectra , oracle.
Current projects: Writing a lightweight content management system (appframework), Kreynet IRC Network
http://www.marbie.net/
