CFInvoke vs. CreateObject

Friday, September 26th, 2008

Most programming languages have what are called static or class methods.  The other kind of method available is instance or object methods.  The difference between the two is that the former acts independently of any data members within the object.  Thus it can be called in passing without instantiating an entire object in order to use a small chunk of code.

Apparently the Coldfusion developers have never heard of these differences.  A tag called CFInvoke exists which would lead one to believe that this works like a static method call.  The first volume of the official Coldfusion text book even hints at this by using it in this way.  It even say, “… although rather than used, CFCs are said to be invoked.”

Well, not exactly.  If you use CFInvoke on an uninstantiated object (by using the component path), it will instantiate it for you.  Everytime. So instead of it being a memory saver, it wastes memory.

The proper use of CFInvoke is if you do not know what function will be called ahead of time and don’t want to have to have a switch statement for each potential function call.

Case Sensitivity In XML

Thursday, September 4th, 2008

Just a quick note to everyone trying to use XML in Coldfusion.  Don’t use a “true” parameter in XMLNew().  Things will go haywire.  Just use false and it manages to still retain all of the case sensitivity.

My hunch for why this makes things go haywire is that you cannot use the normal dot notation for accessing the sub-elements because CF capitalizes anything in the dot notation.

Another related note: don’t use the built-in XSLT processor.  It sucks and isn’t fully implemented.  Use cfexecute and get some sort of external XSLT engine.  The one I’m currently using is Saxon.  It’s slow, but it works.

StringBuffer vs. List

Friday, July 25th, 2008

Just a quick tip that Shayne pointed out to me (after I had spent a few minutes staring at my code), use StringBuffer if you ever need to have a modifiable string.

Coldfusion uses the Java String class rather than StringBuffer. This means that everytime you modify a string, ColdFusion creates a copy of it in the background and doesn’t de-allocate the old one. Obviously this can quickly eat through your server’s memory. If you plan on only doing a few string modifications (or never modifying it), go ahead and use ColdFusion’s built in string class. Otherwise it will be better to use a StringBuffer.  If you ever want to use a StringBuffer object as a normal ColdFusion string, just use the StringBuffer’s toString() method.

Another benefit to StringBuffer is the number of functions available to you for things like substrings and treating the string as an array.  For a good example of replacing a ColdFusion string with a StringBuffer see this post.

Order in != order out

Thursday, July 24th, 2008

Because arrays in Coldfusion are based off of the vector collection in Java, they don’t always maintain their order in every instance.  If you use ArrayToList(), the order of the list returned will come out in whatever random order it happens to be stored in memory.  If you want a quick demonstration, use the following code:

<cfdump var="#ListToArray(StructKeyList(Variables))#" />

Just keep refreshing the page and you will see the order of the array keep changing.

To get around the weirdness with this, try using the java vector’s methods instead of CF’s array methods.  Just remember that the java methods use zero based arrays (versus CF using one based arrays).

Edit: That example isn’t entirely accurate. Scope variables are based off of abstract maps, but the concept is the same.