Shooting the trouble
My goal as a programmer is to understand the languages I use most commonly and to continue to grow my knowledge within the languages and within the technological world as a whole. Since there isn’t much time left in the day to do this when all is said and done, I have to pick and choose what I learn. My latest learning adventure has been about SeeFusion, which should in time help me write better Coldfusion application code by determining wasteful behavior. Alongside that, I am continuing to dive deeper into the language of Coldfusion and the tags that are available to me. Two tags that I plan on spending some quality time with in the near future are CFTrace and CFTimer.
Traditionally when I am debugging a Coldfusion application, I write my code, upload the page, test and see what comes back. If I get an error I have to go through the short process (sometimes) of figuring out why the error happened. If there are no visible errors, but the output is not showing what I think it’s supposed to, that’s the bigger issue. CFTrace should be able to help me out there. Normally what I will do is throw in a CFDump to dump out my variables to the screen so I can find out if they’re being set correctly. CFTrace can do the same thing, only I can set it so that it does not throw out stuff inline. This could be handy for situations where I need to keep the output looking one way, but then show a bunch of information at the bottom of the screen showing the progression of a variable. It can also pop information into the logs if I need it to. This would be very handy if I’m in a CFC where I don’t get output. Then I can specify where I am in the logs, to keep a constant watch as things jump from function to function.
So, since I’ve spent enough time talking about it, I have to get down to making it work. Next week I’ll give up some code and talk about further helping applications move along with cftimer.