Leave that code alone! Part 2

February 27, 2007 · 7 Comments

Just got off a debugging session with a ColdFusion developer. They're using Fusebox 5 and successfully running an existing Fusebox 4 site on it. The developer IM'd me because he was having a problem getting a new application up and running. No matter what URL he tried, the application always showed the same default home page. I suggested a few things in IM but nothing worked. Curious, I fired up my public Adobe Acrobat Connect Professional room and asked the developer to join me. I made him a presenter and asked him to shared his screen and show me his fusebox.xml and circuit.xml files. They looked fine. So I requested control and had a look at a few other files in his application - everything looked fine but the application resolutely refused to display any fuseaction except the defaultFuseaction. As a last ditch idea I edited his fusebox.xml file to explicitly set the fuseactionVariable parameter. Success! This said that the default value being used was not the documented default. I asked him to show me where the Fusebox 5 core files were on his system. I opened up fuseboxApplication.cfc and saw that someone had changed the underlying defaultFuseaction! So, someone had modified the core files to create behavior that was at odds with the documentation and the result was a developer spending goodness only knows how much time trying to figure out why their basic little application didn't work - and then about another hour combined of my time and his, tracking down the problem. Remember folks: Leave that code alone!

View count: 343

Tags: coldfusion · fusebox · oss

7 responses so far ↓

1 Michael Dinowitz // Feb 27, 2007 at 6:24 PM

Were there any documentation as to why the change was made? If anyone is going to fork a framework, that's one of the three requirements. The others, of course, are to know what your doing and have a really good reason to do it. :)
2 Sean Corfield // Feb 27, 2007 at 6:33 PM

@Michael, no, I'm betting some developer just opened up the file, saw the default and went "Oh, I'll just change that - it'll be more convenient for me!"...
3 Michael Dinowitz // Feb 27, 2007 at 8:49 PM

Convenience alone is not a reason. There has to be a fundamentally important reason and most importantly, the change has to work. How in the world did the person who changed the core file not see that it broke the app?
4 Sean Corfield // Feb 27, 2007 at 11:31 PM

@Michael, it clearly did *not* break their *current* app. The problem was that it changed the behavior for the standard, documented skeleton application which is intended to be used as the basis for new applications.
5 Peter Tilbrook // Feb 28, 2007 at 2:11 AM

LOL! Poor bastard(s)!

I had a strange issue I encountered today by accident - still waiting for my Ferrari notebook to come back from repair with 2Gb more memory - my UUID's were "padding".

What I mean is that after the UUID was heaps of spaces. Turns out I to be a database issue that was easily sorted.
6 Richard Tugwell // Feb 28, 2007 at 9:50 AM

@Peter

That wasn't Oracle and NLS_LENGTH_SEMANTICS=CHAR was it? And your UUID fields were defined as CHAR(35)?
7 Anand Paleja // Mar 1, 2007 at 7:47 AM

Ah.... yes...
Pragmatic Programmer Tip #26
"select" Isn't broken

When I first started using FB, not too long ago (started with v4.1) I had a problem and the error message was pointing to a file in the FB core. I swear something was wrong with it ( it obviously wasn't something I coded, I always code exactly right on the first pass... :) ) After about an hour of debugging, low and behold it was my code that was causing the error!

An Architect's View

CFML, Clojure, Software Design, Frameworks and more...