Hi, I’m new to this forum. I wasn’t sure where else to post this, but was wondering if there was a reason for this change which causes a discrepancy when migrating an application from railo to lucee
In railo, val(true) == 1, which equates to true.
In lucee, val(true) == 0, which equates to false.
I know taking the val() of a boolean is probably not great practice, but seeing how databases often store bit fields as 1/0 it is used logically quite often in our legacy application.
Any reason for this change? Does anyone agree this is a bit weird or a logical bug?
Yeah. There is a reason for the change. What does val() actually do? …
Converts numeric characters that occur at the beginning of a string to a number.
If conversion fails, returns zero.
So it’s doing exactly what it says. The previous behaviour was an error and did not match what that function should do.
Also to be fair, it was a bug in Railo it seems. I tried it out at https://trycf.com/ with CF down to version 10 and only Railo was returning 1. So it’s a bug that got fixed.
if you are trying to convert true/false -> 1/0 maybe terniary would be better?
var x = true ? 1 : 0;
Hi, thanks for your answers.
Yes, I guess it was just one of those bugs that was taken as a “feature” at the time. It is interesting that Coldfusion doesn’t do it.
We have only recently made the switch from railo, and in the process this caught us out. There were a number of places that need to be fixed as we were often using val() to clean user input.
We’ve switched it now to either the tertiary operator, as you pointed out, or to clean user input this pattern is quite useful:
var x = (form.x is true);
Which really is more correct as it creates a proper boolean variable, and cfqueryparam does correctly covert a true value to a “1” … So I thought it funny that cfqueryparam can convert true to a number that also evaluates as true, but val doesn’t.
All good. Was just wondering.