tracker issue : CF-3712010

Adobe needs to stop this nonsense about such a completely hosed function having to stay broken for "backwards compatibility". This might make sense in a situation where the functionality is slightly off, but this is not even close.

Comment by External U.

Please make isValid() work properly! At the moment, the function is pretty much unusable since many of its checks are completely unreliable, forcing people to create all sorts of workarounds.

Vote by External U.

So this won't be fixed do to a fear of breaking backwards compatibility yet you are breaking backwards compatibility by "fixing" CFINLCUDE to only allow cfm and cfc files. The later is claiming to be a security fix yet I haven't found a way this is a security issue. Adobe Logic is as messed up as ColdFusion "boolean" (0 for false and any number greater than 0 for true).

Comment by External U.

What they said. Additional characters needed to meet 25 character limit provided by hipster ipsum Sustainable PBR&B fashion axe, ugh Echo Park stumptown readymade farm-to-table tote bag photo booth fanny pack chia selvage Williamsburg. Portland aesthetic Cosby sweater, vinyl blog kogi forage sartorial salvia YOLO Williamsburg. Ethical Austin umami twee, bitters quinoa ugh chillwave messenger bag. Brooklyn chia McSweeney's, lo-fi Thundercats banh mi biodiesel pop-up gluten-free. High Life narwhal mixtape pickled. Trust fund Cosby sweater 90's iPhone. Bitters umami shabby chic, ugh messenger bag seitan letterpress quinoa Schlitz.

Vote by External U.

Wigeno, for the record. Its 0 = False Any other number, positive or negative is True... not just any numbers greater than 0.

Comment by External U.

Don't fix what isn't broken, but THIS IS BROKEN, SO FIX THIS.

Vote by External U.

Absolutely, positively, without question must be fixed!

Vote by External U.

When you have a function that doesn't work the way it's supposed to, then it clearly affects productivity and forces us to write work-arounds when we shouldn't have to.

Vote by External U.

If you really want to provide backward compatibility (which is the same sort of logic that makes Windows such a huge mess at times), you could allow for another method, like "useStrictValidation" where if it's false, it reflects the current behavior, but if it's true, it reflects the correct behavior. Defaulting it to false, while not ideal, would allow for backward compatibility so that the people who have been doing it wrong for years don't have to change their code.

Comment by External U.

There is no question this should be fixed. (Backwards compatibility is not an acceptable reason to defer this bug.)

Vote by External U.

Why in the world would you want backward compatibility to a broken feature?

Vote by External U.

"Why in the world would you want backward compatibility to a broken feature?" could not put it better myself. -- Adam

Vote by External U.

+1 (already voted for #CF-3169196). Perhaps offer JVM arg -Dcoldfusion.isvalidintegerstrict=false for any that need to revert to this current behavior.

Vote by External U.

The way a string is parsed to Integer and date is really crazy and that is why the method that does this also has the name starting with "crazy" :-) It has been like this forever (probably since Version 1) and making such a fundamental change has a great potential to break a lot of applications. As dsbrady_98 said, it might be possible to add a flag to retain the backward compatibility, we don't want to make such a fundamental change so late in the cycle and that too in a behavior that has been there probably since version 1. We plan to take up such changes in 'Dazzle' where we will correct the behavior without worrying about backward compatibility.

Comment by Rupesh K.

But how, Rupesh? HOW could it break other applications? Are you honestly suggesting that people are taking a function that just DOESN'T WORK, and somehow relying on this broken behaviour in their code? And you think it's more important to protect against this stupidity than make the language work for everyone else? As I said in here: http://cfmlblog.adamcameron.me/2014/02/fixing-any-bug-has-backwards.html... *prove it*. Where's the evidence of this code leveraging behaviour which outright *doesn't work*. You can't just hold the language to ransom with what seem to be completely fictitious excuses for not doing work. Before you can cry "great potential to break a lot of applications", you actually need to have evidence that this might be the case. NB: isValid() has only been in the language since CFMX7. But you can't legitimately even say "well there's three versions worth of code relying on this then", because no code WILL BE relying on it. And if for some completely mental reason there was... that code SHOULD break. And it's just... really a bit rubbish that your attitude is "well it's been broken for ages so what does it matter when we fix it?". Your attitude should be "Shit! this has been broken for ages! We should fix this!" Where's your sense of pride in your work? -- Adam

Comment by External U.

Since isValid("integer", "$1,234") returns true, but isValid("integer", "$1,234.56") returns false, no code would, IMO, be using isValid("integer") to validate a "currency string" unless they're only validating whole dollar amounts =P How about just adding isValid("numericinteger", foo) to the language? Thanks!, -Aaron

Comment by External U.

I meant isValid("integer", "$1,234.00") geez. Tired. What I meant was: A "currency string" (a number beginning w/ a "$") would normally have a "." too. So, since isValid("integer") only returns true if there's no decimal, then there'd be no code, IMO, that's using isValid("integer") to validate "currency strings". B/c even if someone's storing currency values in a varchar db field (along w/ the "$"), they'd have to be trimming the ".00" off in order for isValid("integer") to return true for "currency strings" representing whole dollar amounts. Sry for rambling.. just tryin' to think of -any- valid scenario where someone would be expecting isValid("integer") to return true for a number that has dollar signs and commas mixed in. Thanks!, -Aaron

Comment by External U.

First of all, it is not about IsValid only. It is about how a string is parsed as integer/Number and how the validation is done all over the place - be it validation of function arguments, or a tag attribute or cfparam or form validation (there might be some more). It is very easy to say that applications would not break OR these applications should break because you wouldn't have to handle the support calls when they break :-) The validator allows common currency characters($£¥€), comma(,), plus (+) and dot (.). Some of the example for strings that this functions allows which people have been using are 10,000,000 $10,000,000 $ 10,000,000 $ 10,000,000.00 +10,000,000.00 Applications rely on these values being treated as integer/number and we can't break them. As I said earlier, the validation logic is definitely not correct and should be fixed along with the inconsistencies in integer/number parsing but we can't do it now as it is too late. We plan to take these kind of changes in Dazzle.

Comment by Rupesh K.

Well you've got a problem right there then. Because "$10,000,000.00" doesn't validate as an integer. Anyway, you still just don't seem to get it. This *isn't* about what constitutes and integer in CFML, it's about a) uniformity of the language; b) *validating* what can be used as an integer. The isValid() function should only return true for values that CAN be used as an integer. And, as demonstrated, IT BLOODY DOESN'T. It does not behave in an internally-consistent fashion with other functionality in CF. It will false-positive an awful lot of values which completely are not integers in CFML's view. We're not trying to get you to change what an integer is as far as ColdFusion is concerned, we're asking you to RESPECT what is an integer as far as ColdFusion is concerned. This is why we're all so bemused about your assertions of backwards compat issues. The thing *doesn't work*. Not in the context of how we'd like it to work. In the context of how the rest of *ColdFusion* expects it to work. -- Adam

Comment by External U.

Case in point: <cfset amount = "$10,000,000"> <cfif isValid("integer", amount)> <cfset result =amount * 1> </cfif> Output: The value $10,000,000 cannot be converted to a number. The error occurred in D:/HostingSpaces/russ@michaels.me.uk/code.cflive.net/wwwroot/coldfusion/1B80FBAC-98C5-4344-BB7C8A88D994B36C.cfm: line 3 1 : <cfset amount = "$10,000,000"> 2 : <cfif isValid("integer", amount)> 3 : <cfset result =amount * 1> 4 : </cfif> *do you understand what we mean, now*??? -- Adam

Comment by External U.

Interesting stuff.. Just doing some messing around too: 1) cfparam and isValid("integer") disallow the dot(.) (so my post about "currency strings" still stands) 2) isValid("numeric") allows the comma(,) but isNumeric() doesn't (weird) 3) 1,000 * 1 = 41639 (??) <cfscript> param name="foo" type="integer" default="$1,000.00";//throws exception: "The value specified, 1000.00, must be a valid integer." writeOutput(isValid("integer", "$1,000.00"));//returns NO </cfscript> <cfscript> writeOutput(isValid("numeric", "$100"));//returns NO writeOutput(isNumeric("$100"));//returns NO writeOutput(isValid("numeric", "+100"));//returns YES writeOutput(isNumeric("+100"));//returns YES writeOutput(isValid("numeric", "1,000"));//returns YES writeOutput(isNumeric("1,000"));//returns NO abort; </cfscript> <cfscript> number = "1,000"; writeOutput(isNumeric(number));//returns NO writeOutput(isValid("numeric", number));//returns YES writeOutput(number * 1);//returns 41639 </cfscript> I did verify that isValid("integer") allows the plus(+).. and so does isNumeric().. so we can't just do <cfif isValid("integer", foo) and isNumeric(foo)>. Hmm, wow.. can't wait till this is all fixed! =) Thanks!, -Aaron

Comment by External U.

Crazy tired, but this is too interesting.. So, I just verified: cfargument's type="numeric" also allows the comma (,). Applications are already broken in a serious (IMO) way. Just run the following and click submit. <cffunction name="increaseCount" returntype="void"> <cfargument name="increaseCount" type="numeric" required="yes" /> <cfif isValid("integer", ARGUMENTS.increaseCount)> <cfset var currentCount = 200 /><!--- Query would get current count from db ---> <cfset var newCount = ARGUMENTS.increaseCount + currentCount /><!--- Query would update db w/ new count ---> <cfdump var="#currentCount# (currentCount) + #increaseCount# (increaseCount) = #newCount# (newCount) (bad!)" abort="true" /> </cfif> </cffunction> <cfif structKeyExists(FORM, "increaseCount") and isValid("integer", FORM.increaseCount) and isValid("numeric", FORM.increaseCount)> <cfset increaseCount(increaseCount=FORM.increaseCount) /> </cfif> <cfform> Increase count: <cfinput type="text" name="increaseCount" value="1,000" /><cfinput type="submit" name="submit" value="submit" /> </cfform> This affects any code that does simple math on a user-input number, containing a comma, that CF says is both an integer and numeric. At least.. it appears to be so in my current sleep-deprived state. I truly hope I'm missing something obvious here. Thanks!, -Aaron

Comment by External U.

When we import data from a CSV or Excel file, ColdFusion indicates that the user-entered values like "1,000" are valid integers, but apply a VAL() to that and the valid integer becomes simply "1". If passed untouched to SQL, an error also occurs because SQL doesn't doesn't agree that "1,000" (with the text comma") is a valid integer. Please fix. (We've also had issues where a non-breaking space after an integer in Excel isn't trimable using trim() and caused problems during import.)

Vote by External U.

<cfinput validate="integer" allows: 1) +$1,000 (so, same behavior) 2) 9999999999999999 (so, a little worse)

Comment by External U.

If Adobe seriously thinks that there are developers using this incredibly broken function that need to continue using it, why not simply provide an alternate version for something like "numericString" or whatever you want to call it. Doing a sitewide search-and-replace if you want to continue using the current buggy implementation is not an unreasonable thing to expect developers to do if they have so poorly coded their sites to validate something as integer that is NOT an integer. There are far too many of us that have been burned by the broken functionality of this and leaving it in place is just another reason developers turn away from CF as buggy and quirky. The fact that you are deprecating a considerably large list of tags and attributes and don't seem concerned whatsoever that THOSE will break existing sites (which would be using them without even relying on broken, buggy implementations) makes the logic behind not fixing this even MORE absurd.

Comment by External U.

Adobe: Preserving legacy bugs because you've had to code around these bugs for so long that if we fixed the bugs we'd break your code.

Comment by External U.

Ray Camden reported this issue back in CF7 before July 31, 2005 (https://bugbase.adobe.com/index.cfm?event=bug&id=CF-3024044) and it was deferred with "not enough time". Since this issue was migrated from the old bugtracker, no votes are listed. Ray followed up with a suggested flag or workaround before August 3, 2005 (https://bugbase.adobe.com/index.cfm?event=bug&id=CF-3024112) and it was deferred with "not enough time". Despite this bug being migrated from the old bugtracker, it got two votes. ErnestoRA reported a similar issue in CF8 on September 1, 2010 (https://bugbase.adobe.com/index.cfm?event=bug&id=CF-3042116) and it was closed with "NeverFix". MisterDai reported similar issues with IsValid in CF8 on September 20, 2010 (https://bugbase.adobe.com/index.cfm?event=bug&id=CF-3042202) and it was deferred with "not enough time". This issue got one vote. MaryJo reported similar issues with IsValid in CF9 on April 18, 2012 (https://bugbase.adobe.com/index.cfm?event=bug&id=CF-3169196) and it was closed as "Withdrawn/AsDesigned". This issue had 15 votes and 4 comments from end users. Now MaryJo has once again reported this against a BETA version of CF11, and it is again being deferred? Are you kidding? With 10 votes and 14 comments from end users telling you to fix it? So after more than eight years of begging, six different bug reports against four (really five if you implicitly include CF10) different releases, more than a dozen unique end users weighing in with comments, and at least 28 votes to fix this issue (with recognition from those commenting/voting that dealing with any backward compatibility issues would be preferable to maintaining the status quo on broken functionality), you still want to push this off to yet another future release? After continually deferring it since 2005? This MUST get fixed during the current BETA cycle. Waiting until CF12 (maybe) to get this resolved is ABSOLUTELY UNACCEPTABLE (especially to those of us who have been paying for upgrades to the product over the years).

Comment by External U.

This is a f***ing travesty. Rupesh, you should be personally embarrassed regarding this, and you should also be embarrassed on behalf of Adobe (well: at least the ColdFusion Team, not the whole company). -- Adam

Comment by External U.

What's particularly maddening about this is we are not so stupid as to believe that this is a hard or complicated fix that really is going to take any significant time to do. Heck we can write a custom function to do this in less time than I've spent discussing it on this bug report! Validating an integer is NOT something hard to do!! So if you really think the existing implementation has ANY use at all to someone, copy it to a different isValid() setting as I suggested and FIX the integer one to check for actual integers!!

Comment by External U.

I'm all for maintaining backwards compatibility, but I'm also all for fixing the parts of the language that are broken. This is one of the things that really ought to be fixed sooner rather than later. This again comes down to a) what an educated developer expects this function to do... which is return only true for actual integers (no currency, commas, decimals, whatever) and b) properly educating developers on the change to proper (expected) behavior. I, personally, have never run into code that intentionally uses (or, in this case, misuses) this validation for non-integer numbers except perhaps for validating user/data input and, in those cases, it should be implemented properly in the first place. If it isn't, it isn't... but I have to imagine the number of applications that misuse this function are that numerous as to prevent you from fixing it. As for the larger validation problems with CFML - yes, they should be addressed in the next release if not this one... but this should be a relatively easy fix... if only by implementing a strict processing flag as already suggested... so it should be doable for this version.

Vote by External U.

Wow - it is indeed incredible. Thanks Carl for digging this out. We will fix it - we would have a application setting which would bring back the old behavior in case some one needs it. I hope nobody needs to use this flag. We will also roll it out in an update for the public beta and we would need your help in verifying and making sure that applications don't break. Thank you everyone for raising this and providing this feedback!

Comment by Rupesh K.

Thank-you Rupesh.

Comment by External U.

Added a new application level setting strictnumbervalidation to allow/disallow strict checking of numbers. The default value of this setting is true which will do a strict check for numbers and won't allow any special characters. To bring back the old behavior set the value of this setting to false.

Comment by S V.

Thanks Rupesh for changing position on this and listening to the community. And especially Carl for digging up all that history!

Comment by External U.

Just to add - this strict checking will be for both integer & numeric. The same validation will kick in for function argument, cfparam and cfform

Comment by Rupesh K.

Rupesh - great news! And the consistency in validation between isValid(), <cfparam>, <cfform>, and function arguments (the "type" attribute) is also excellent. Will this extent to the "validate" attribute of <cfproperty>?

Comment by External U.

yes, cfproperty as well.

Comment by Rupesh K.

Excellent! Thank you for addressing this long standing bug!

Comment by External U.

Thank you for changing your position on this. isValid() has been broken ever since it was added so this will be a long-awaited bug fix!

Comment by External U.

w00t!! awesome, thanks!

Comment by External U.

Big thanks to Carl and itisdesign for all the research making this get through. Hopefully some other bugs will also see the light of day.

Comment by External U.