RE: [CFCDev] How to deal with "empty" objects without Nulls?

[Andrew Powell]

But what about when we start dealing with Flash Forms where you bring ActionScript and strict datatyping into play?  There is going to be a time and place, maybe with Flex, where we will see null values and not empty strings.  If you move into Flash Forms (Flex Lite), you will see strict-datatyping come into play.   my 2 cents.   ap From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando Sent: Wednesday, April 12, 2006 4:09 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] How to deal with "empty" objects without Nulls? When working with web applications, i think it's important to keep in mind that a form only submits variables as strings. There are no data types in HTML. So any data that your users submit to the app is going to originate as a string. And ColdFusion doesn't have a concept of null, so i believe you'll get an empty string in CF when a null is returned from a database query. To me, that translates into a simple understanding: trying to strong type all your arguments in CF is going to be laborious, maybe a waste of time. So in cases where a value could be null in the database, or could be submitted from a form, to me, the argument type should be "any" or "string", because that's the reality, and any validation that should happen before persisting it or manipulating the variable needs to be in a validate method. You can also consider strong typing your arguments and catching the wrong type errors, but there's no simple, clean way to do that. Strong typing arguments that can possibly receive other types in normal application flow implies handling wrong type errors as part of the application flow. It's not really an application exception. To me, that's not right. Error handling isn't for normal application flow. So strong typing in these cases doesn't seem right to me. I find it easier and cleaner, in CF's loosely typed environment that meshes well with HTML's typeless environment, to just go with the flow and loosely type my arguments in all cases where the type is not fixed in stone, and handle validation after the variable is passed into the method. If a real exception happens at some point that involves that loosely typed argument, a runtime error will be thrown anyway. It might not be a wrong type error, but something else will error out a few milliseconds later. Does that make sense? Daniel Roberts wrote: I have objects that have instance variables with setters/getters requiring types such as uuid and date. If the object is "blank" the variables will be empty strings, which cause errors when getting or setting to blank, or bad data if I start them off with values to match their types (1/1/0001 or AAAA-AAAA-AAA etc) which just feels wrong. The way around this is to allow any type of data through the setters and getters with some extra custom validation code or getting/setting instance data structs. Neither of these seem right. Am I missing something here? ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org -- Aria Media Sagl CP 234 6934 Bioggio Switzerland www.aria-media.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org