> Yeah, you're completely missing the point. You're explicitly relying
> on CF's interpretation of null to be a non-numeric simple value (i.e.
> the empty string), rather than actually checking to see if the field
> is null (which is what you should be doing).
Perhaps I'm missing the point because you make blanket statements such as
this without explanation. Why is it better to check that a childID is not
null rather than check to see if it is numeric? The following seem pretty
equivalent to me:
<cfif not isNull(childID)>
<cfif isNumeric(childID)>
I should say that they are equivalent with the exception that the second
seems easier to read and actually performs some level of validation of the
on the data.
> Either way, you're
> testing to see if some field returned from the DB is the empty string,
> and assuming that the empty string means that the field was actually
> NULL.
Enter the straw man. You've completely misrepresented what I said.
isNumeric() does not test to see if a string has zero length. It checks to
to see if the value can be converted to a numeric data type. That's
fundamentally more useful that checking to see if something is not unknown
(i.e. not a null value). It's a much safer approach to say isNumeric()
rather than isNull() because the former validates what the data is while the
latter only validates one thing it is not.
Assume for a moment that you have a form which allows you to add and edit a
record. In one instance, the data comes from the request, in the other, the
database. The request is not going to hand me null values. I'm going to get
strings that I'll need to type check (isDate(), isNumeric(), etc.) before
attempting to format or encode them. You're arguing that it's better to
check that a value is not null, which means I'm left with the following:
<cfif not isNull(someDate)>
<cfoutput>#dateFormat(someDate)#</cfoutput>
Now, what if the user enters a value that is not a date. I better check for
that:
<cfif not isNull(someDate)>
<cfif isDate(someDate)>
<cfoutput>#dateFormat(someDate)#</cfoutput>
How's that better than just:
<cfif isDate(someDate)>
<cfoutput>#dateFormat(someDate)#</cfoutput>
> I'm not going to argue that CF is wrong; CF's strength is in how it
> abstracts complexity into simple things, and this is a good example.
> It's just kind of frustrating that you can't do it the "right" way if
> you want to.
I'd like to see some code that clearly demonstrates an advantage to the
"'right' way". I've seen a lot of code in languages that do support null
values. In the presentation and business tiers, it adds a great deal of
complexity and, with it, points of failure. I see no benefit.
Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
