This is more of a note than anything else concerning an error that throws when trying to run a switch case against a variable. Before analyzing this I want to simply display a function that illustrates a working switch statement, and then the same switch statement replacing the case value with a variable. Let’s take a look.

Working switch statement

public boolean function dynamicSwitch()
{
	var data1 = "matthew";
	var data2 = "cook";

	var expression = data1;

	switch(expression)
	{
		case "matthew":
		{
			return true;
		}

		default:
		{
			return false;
		}
	}
}

Throws an error

public boolean function dynamicSwitch()
{
	var data1 = "matthew";
	var data2 = "cook";

	var expression = data1;

	switch(expression)
	{
		case data1:
		{
			return true;
		}

		default:
		{
			return false;
		}
	}
}

So the second example uses the variable ‘data1′ as the value for the case. This throws a Coldfusion error indicating that case values must be constants (a hard-coded value). This makes sense, and maybe you’re wondering why a variable would ever need to be used for the case value. Admittedly, it certainly makes no sense in the above example, but I do personally like to declare all component constants at the top of my component by storing them in a ‘constant’ namespace and prefixing the variable name with a ‘c_’. Coldfusion doesn’t literally support constant variables, so having some rules around how to syntactically declare constant variables in Coldfusion makes sense to me.

So in my case I had set some constant variables in my component, and in a function needed to compare a passed in argument against them. It was a scenario where the value either would or would not equal the value of one of my constants. Hard-coding those values again for a switch statement would have been plain old bad practice. Nonetheless, it was also in this scenario that I learned I could not use a variable for my case value.

The result was that I used an if-else statement instead. It works fine. The switch statement would have been more appropriate, but take what you can get I guess.

I just previously wrote a post on the loose data typing in Coldfusion and how, although I could see the potential for problems, I have never actually had any issues that I’ve known about due to not having strict data typing. As fate would have it, of course, I ran into an issue today related to data typing using the Coldfusion compare() function. The issue is when two numbers get accidentally typed as a string behind the scenes and it doesn’t become known until you realize that there are inaccuracies in the comparison. It’s very important to note this because it almost made it past me.

The issue occurs when you compare the strings of integers and they get compared not as an integer, but as strings. The difference is that integers get compared as whole numbers, while strings get compared on a character by character basis. So for example comparing the string “3″ and the string “100″ will indicate that “100″ is less than “3″. The reason for this is because when looking at the first character “1″ is indeed less than “3″. Comparing the two as integers will of course indicate that 3 is less than 100.

So speaking more specific, the next thing to note is that the compare() function compares strings. This essentially makes it useless comparing integers. Maybe I’m wrong, but a quick search of the docs didn’t return any comparison function for integers. So the only way I know to handle it is to use an if/else statement. Let’s take a look at what we’re dealing with using the compare() function to compare either integers typed as strings or integers typed as integers, because the compare() function will implicitly type the data as strings.

String Comparison (cfscript)

public void function typeDataCatch()
	displayname="Type Data Catch" hint="Shows a data type catch using compare function." output="false"
{
	var data1 = "2";
	var data2 = "100";

	var dataComparison = compare(data1,data2);  //returns 1 indicating that 100 is less than 2
}

(more…)

Another issue I ran into when converting some older Coldfusion 8 applications over to a Coldfusion 9 server concerning tabs using the tag. Unlike getDataSource() this issue is a Coldfusion 9 bug. The issue is that if you create a tab layout the first tab does not have an auto-height property. That being said, no matter how much content you put inside the region it will never expand to show the content.

MrTee posted on the Coldfusion 9 docs both the problem and the solution. This is not my solution, I’m just spreading the word here. The link to his comment is here. He has also posted the correct javascript file here.

The problem needs to be corrected in the layout.js file. If you are in your wwwroot folder look under CFIDE/scripts/ajax/package directory. Once you have this file open you can make the changes as expressed by MrTee himself.

“The change I made is on line 70 and changed from

var _70=new Ext.Panel({title:_6a,contentEl:_68,_cf_body:_68,id:_69,closable:_6c,tabTip:_6b, autoScroll:_6f,autoShow:true});

to

var _70=new Ext.Panel({title:_6a,contentEl:_68,_cf_body:_68,id:_69,closable:_6c,tabTip:_6b, autoScroll:_6f,autoShow:true,autoHeight:true});

I hope this helps anyone with the same problem out.”

All in all an ‘autoHeight:true’ needs added to the Panel() method. As far as I know this has not been addressed in an update by Adobe, but has been acknowledged. I used this solution and it worked perfect with no known side-effects on my own applications.