ColdFusion's ToScript() Function Works Differently in CF11 than in CF2018. Why?

[Dordrecht]

Hi all

We upgraded from CF11 to CF2018 recently.  Today we found a JavaScript error due to a difference in the way ColdFusion's ToScript() function returns its data. 

The ColdFusion structure going into the ToScript() function looks like this:

<cfdump var=#allowedLevels# />

The above structure is passed to ToScript() as follows: 

var #toScript(allowedLevels, "allowedLevels")#

In CF11 the results look like this:

var allowedLevels = new Object();
allowedLevels["1"] =  new Array();
allowedLevels["1"][0] = "1";
allowedLevels["1"][1] = "2";
allowedLevels["2"] =  new Array();

In CF2018 the results look like this:

var allowedLevels = new Object();
allowedLevels["1"] =  new Array();
allowedLevels["1"][0] = 1;
allowedLevels["1"][1] = 2;
allowedLevels["2"] =  new Array();

As you can see, the values in the second dimension of the array are created as Strings in CF11 and as Integers in CF 2018. Can anyone offer the reason why this is occurring, and how to fix it?

Thanks in advance.

[Charlie Arehart]

That's indeed an interesting one. Can you confirm first what update level of CF2018 you are on? There have been 16 updates.  This could have been addressed by one you have not applied. You can cfdump/writedump the Server scope to see your update level, or view it in the CF Admin on the settings>"settings summary" or updates>"server updates" pages.

Next, rather than blame the toscript, have you tried simply doing a dump of the allowedlevels var, to see if the problem is in there even BEFORE toscript tries to do its work?

Finally, if neither of the above help, can you offer teh code that builds the "allowedlevels" (or hard-code something to create it, that leads to that same result in the toscript)? That way folks wanting to help can answer some questions for themselves and/or perhaps offer alternative solutions.

[Dordrecht]

It happens on update 9 of CF2018 on my local machine and I believe the latest update of CF2018 in the live environment, so update 9 and above, at least.

I did indeed just backtrack to the code that creates the array, and the array occurrences in question are created like this:

<cfset local.retVal["1"].append(1) />

<cfset local.retVal["1"].append(2) />

...so they ARE integers, and CF2018 is interpreting them correctly.

Still, if there was a change betwewen CF11 and CF2018, I wish there was some documentation to let us know. (Maybe there is and I just couldn't find it.) Because CF11 ToScript() was producing strings, the JavaScript that uses the results of ToScript() was coded to expect strings, which now fails, so the fix broke the code. :).

[BKBK]

Dordrecht ,

I agree with you that Adobe has to inform the community of any such changes. In any case, I think the above change is an mprovement. With integer values, you get integers; with string values, you get strings. So, you will be changing your code for the better. 🙂

[BKBK]

Backward-compatibility is one of the mantras of the Adobe ColdFusion team. So, report this change as a bug. 

[Dordrecht]

[Update] Please note that we are experiencing the same issue with the CFWDDX tag when it uses the CFML2JS action. A ColdFusion array containing true and false bolean values in CF11 spat out "true" and "false" in the resulting JavaScript. In CF2018, the values are spat out as true booleans, with no quotes:

In CF11:

vendorNumberArray =  new Array();
vendorNumberArray[0] =  new Array();
vendorNumberArray[0][0] = 123456;
vendorNumberArray[0][1] = "true";
vendorNumberArray[1] =  new Array();
vendorNumberArray[1][0] = 234567;
vendorNumberArray[1][1] = "false";

In CF2018:

vendorNumberArray =  new Array();
vendorNumberArray[0] =  new Array();
vendorNumberArray[0][0] = 123456;
vendorNumberArray[0][1] = true;
vendorNumberArray[1] =  new Array();
vendorNumberArray[1][0] = 234567;
vendorNumberArray[1][1] = false;