On 9/30/05, Barney Boisvert <[EMAIL PROTECTED]> wrote:
> Whoops. I meant trailing space, not trailing slash. Sorry about
> that. Basically CF says "34 " is a valid numeric value, in all MX
> versions. Here's a better test to illustrate:
>
> <cffunction name="t" output="false" returntype="numeric">
> <cfargument name="a" type="numeric" required="true" />
> <cfreturn a />
> </cffunction>
>
> <cfoutput>
> <pre>
> <cfloop list="34,34 , 34" index="i">
> #i# : #isNumeric(i)# : _#t(i)#_
> </cfloop>
> </pre>
> </cfoutput>
>
> Surely this is a bug?
>
Well, again, I see cfargument's under-the-hood validation logic
trim()-ing the value before validating (or while validating if it's
using a Reg Ex), but I guess the bug problem statement becomes this:
Is it a bug that a numeric value with a leading or trailing space
passes cfargument's validation?
I'm not sure. I mean, on the one hand, I certainly see your argument
(no pun intended) that a space in a non-numeric character. At the same
time though, in the context of an individual number, the leading or
trailing space does not change the fact that it's a number. If you
have these three:
34
[space]34
34[space]
The end result is still 34 -- you don't change it's value/meaning by
pre-pending/appending space. So the fact that cfargument validator is
trimming the space around the value doesn't really matter to me. If
I'm in a situation where I'm putting two arguments together to make a
number (i.e., argument x is 3, argument y is 4, return 34), then it is
up to my custom logic to properly trim the values first (<cfreturn
trim(arguments.x) & trim(arguments.y) />.
All that being said, this is what I feel is a bug. Let's modify your
example to add one more list element:
<cffunction name="t" output="false" returntype="numeric">
<cfargument name="a" type="numeric" required="true" />
<cfreturn a />
</cffunction>
<cfoutput>
<pre>
<cfloop list="34,34 , 34,3 4" index="i">
#i# : #isNumeric(i)# : _#t(i)#_
</cfloop>
</pre>
</cfoutput>
That yields:
34 : YES : _34_
34 : YES : _34 _
34 : YES : _ 34_
3 4 : NO : _3 4_
And yet the UDF has no issue with that last "3 4" passed in even
though isNumeric() returns NO in the calling code. So the
under-the-hood validator looks like it's trimming all whitespace from
the value, regardless of where it is found in the number, and that's a
bug to me as it changes the value of the number passed in.
By the way, all my tests are against the 6.1 (fully patched) and 7.0.1
final release; I don't have a pure 7.0 around anymore.
Does that make sense?
Regards,
Dave.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting hours spent on a project or with a
client with Logware today. Try it for free with a 15 day trial account.
http://www.houseoffusion.com/banners/view.cfm?bannerid=67
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:219782
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
