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

[Nando]

Daniel Roberts wrote: That makes sense and was a way I considering approaching this but didn't feel right due to the idea that cfcs/classes are supposed to be self documenting. Consider a property called quantity. In human terms, it's pretty clear that quantity is supposed to be a number. And yet, for an object that needs to interact with web forms and handle null values from a DB, an argument type of string is correct and accurately self-documenting. You can use the hint for more information if needed. Please describe your approach to "validation methods". Thanks Again, consider a property called quantity in a object with methods getQuantity() and setQuantity(). In your DB, the quantity field is a numeric and Null is allowed on the field. So a) you need to make sure it's a numeric before persisting it. And b) CF will hand you an empty string if you query the DB and quantity is null. Here's your setter that will accept any possible value from either a web form or your DB <cffunction name="setQuantity" access="public" returntype="void" output="false">   <cfargument name="quantity" required="true" type="string" />   <cfset variables.quantity = arguments.quantity /> </cffunction> Here's a simple example of a validate() method that would live in the same object. <cffunction name="validate" access="public" returntype="boolean" output="false">   <cfset var isValid = true />         <cfif NOT isNumeric(variables.quantity)>         <cfset isValid = false />         <cfset variables.validationMessage.quantity = "Please insert a number in the field below">     <cfelse>         <cfif variables.quantity LT 1>             <cfset isValid = false />             <cfset variables.validationMessage.quantity = "Please insert a quantity greater than 0 in the field below">         </cfif>     </cfif>         <cfreturn isValid /> </cffunction> <cffunction name="getValidationMessage" access="public" returntype="struct" output="false">     <cfreturn variables.validationMessage /> </cffunction> Your controller would call validate() after populating the (session-scoped) object from a form, and if it returns false, redirect the user back to the form, which would display the appropriate validation message. This is just a quick, simple example. Even if we could work with NULLs in CF, you still couldn't type setQuantity() as numeric and be able to accept values from a web form. You'd need to build 2 objects - a bean for the form and a business object for the rest of the application that would only be populated from a validated bean. Some people go that route, but i don't see the need. As a personal preference, i like simple solutions. :) n. On 4/12/06, Nando <[EMAIL PROTECTED]> wrote: 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 -- Aria Media Sagl CP 234 6934 Bioggio Switzerland www.aria-media.com