The Occasional Danger Of ColdFusion's Automatic Data Type Conversion
Posted December 2, 2008 at 10:26 AM
ColdFusion does a lot to help you out as a programmer. In that vein, ColdFusion will often convert data types for you as it sees it necessary. Unfortunately, that can come back to bite you if you are not careful. This morning, I spent a solid 45 minutes trying to debug an XML error because it didn't occur to me that I was getting a little extra help. To demonstrate, here is an example of the problem I was running into:
Launch code in new window » Download code as text file »
- <!--- Create an XML document. --->
- <cfxml variable="xmlData">
-
- <data>
- <node>Ben Nadel - Kinky Solutions</node>
- </data>
-
- </cfxml>
-
-
- <!--- Check equality of DUPLICATE nodes. --->
- <cfif (xmlData.data.node EQ Duplicate( xmlData.data.node ))>
-
- Equal!
-
- <cfelse>
-
- Not Equal!
-
- </cfif>
As you can see here, I am duplicating a given XML node and then comparing it back to the original. Now, if you program in other languages like Java or Javascript, because an XML node is a complex object, you would assume that this would output "Not Equal!" since we are comparing an object to a clone of itself. However, when I run the above code, I get the following output:
Equal!
What I forgot was that when performing equality tests in ColdFusion, ColdFusion tries to convert the objects in question into simple values and then compare the rendered simple values. So, when comparing two XML nodes, the pseudo code for this is actually:
ToString( XmlNodeA ) EQ ToString( XmlNodeB )
When we keep this in mind and think again about comparing an XML node to the Duplicate() of itself, we realize that of course it will always be equal since the string equivalent of the two nodes will always be the same.
This type of automatic data type conversion can be awesome; but, if you forget that it is happening, it can come right around and bit you in the butt! Now, I am not arguing against this - I love that ColdFusion will do this for us; I am just saying that it is important to keep this behind-the-scenes functionality in mind.
Download Code Snippet ZIP File
Post Comment | Ask Ben | Permalink | Other Searches | Print Page
Newer Post
Overriding ColdFusion's ArgumentCollection And An Extremely Weird Behavior!
Older Post
Update: Sorting Target XML Node Sets In ColdFusion XML Documents
Reader Comments
Oh yes, I've had this happen to me too. Here's one I encountered:
I had an application where I wanted to display a price value. If the price value had no cents, but the user typed in an ending ".00", I wanted to remove this, and just display the whole dollar amount (e.g. $25 instead of $25.00). So being the smart programmer, I just looked for a ".00" as the last three characters and dropped them if it existed. I tested it, and if worked just as desired.
The first day in production, someone calls and says they keep entering $6,000 but it shows up on the web as "$6,". What!! I test this myself, and yep, the last three zeros are getting dropped. I scour the code, write a little test, and CF keeps thinking ".00" is equal to "000". Of course any human can see these strings are not equal.
They may look like unequal strings to me, but to CF they're the same. Why? Well, CF looks at the first ".00" and decides that this can be interpreted as a numeric ZERO, so that's how it treats it, as numeric. Then the "000" can be interpreted as a numeric ZERO too, so ZERO equals ZERO and those last three zeros are going to be dropped from the value and "$6," is going to be displayed.
The solution is to use the compare() function, which does a string comparison.
@Steve,
Yeah, "zero" can be tricky cause it can also convert it into a numeric date/time. When it does things like that, I think you can get odd things like ".00" equaling "0AM".
Compare is one way to handle that... I tend to prefer int() if not lsnumberformat() or numberformat(). But for that matter, even rereplace(string,"\.00$","") should work fine.
