That was one hell of a rant.  I started using Perl as my first web dynamic
language back in college.  That being said and for everyone who feels the
pain of Perl, you will be in regex hell for your stay in Hotel Perl Mod.
What I did get from Perl was the positive side of regex, I use regex to
validate cfform controls.

I agree with the usage of commas, but I have plenty of financial clients
that will disagree with you on the integer.  Commas are just a
presentational way of showing large numbers more legibly.  I do not advocate
allowing the entering of number and I provide both client side and server
side validation for any user entered information.

Your complaint is valid, but there are plenty of ways to go around it.

I do not expect the CF language to have a validation, function or tag that
will magically solve every issue.  What I do expect and CF has always
provided is the ability to combine all of the features of CF to accomplish
them.  CF has so many ways to approach a solution that people can get lost
in translation.

I hope that you do not use a cfform validation as your reason to leave the
realm of ColdFusion.  ColdFusion is still the easiest way to achieve a lot
in a short amount of time.

Teddy


On 9/5/06, Justin Holzer <[EMAIL PROTECTED]> wrote:
>
> How is "1,235" considered an integer? I know that ColdFusion is a lossely
> typed language, but what CF programmer is writing code like <cfset myNumber
> = 1,234 /> ?
>
> Not only is it wrong to validate numeric input with commas, it's
> counter-intuitive, illogical, and just plain insecure. If the programmer
> wishes the user to be able to enter commas, that's fine, but it should
> certainly not be the default behavior, especially when the validation did
> not work that way prior to MX 7. I don't understand why the person/people
> who developed these most recent validation functions did not think
> programmers would not want the numeric data to be something that could be
> stuck straight into a SQL query as a numeric data type. Commas should be an
> exception, not the rule. Add a new validation function called
> "numberWithCommas" or something like that, but why break something that
> works just fine?
>
> What's even worse, is the number validation functions will allow an
> arbitrary number of commas at arbitrary positions. So the user can enter
> "1,,,,,,2,,,3,,,,,,,,5" and it will validate just fine. This is because
> whoever wrote the validation JavaScript (located in cfform.js) decided it
> would be a wise idea to strip the commas, and other special characters, from
> the input string before validating it. However, these characters are not
> stripped from the user's actual input, so the JavaScript is validating
> something different that was actually typed. I don't see how you can call
> this anything but a bug.
>
> I've been a huge fan and supporter of ColdFusion since I started using it
> in version 5. However, this recent discovery has caused me to lose a lot of
> faith, because data validation that is something that I fell can not be
> overlooked in the slightest, as it apparently has been in MX 7. I for one,
> will be using custom regular expressions, until Adobe either issues a fix
> for the validation functions, or the new version of CF is released, and I
> would suggest that everyone else do the same, as that current numeric
> validation functions pose a serious security risk and allow users to easily
> crash your application if you do not know what to expect.
>
> As a footnote, I've also had issues with the validate="telephone" function
> as well. I would suggest for anyone that extensively uses the validation
> feature in <cfform> elements, to write their own custom regular expressions
> for as many of the validation types as possible. Of course, you could also
> make changes to the cfform.js script, but that probablly isn't the wisest
> idea for a long-term solution.
>
> Regards,
>
> Justin Holzer
>
> >I was gonna say, I thought an Int was just a whole number, meaning no
> >fractions or decimals correct?
> >
> >Commas should be allowed past that shouldn't they?
> >
> >>
>
> 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting,
up-to-date ColdFusion information by your peers, delivered to your door four 
times a year.
http://www.fusionauthority.com/quarterly

Archive: 
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:252189
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe: 
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4

Reply via email to