CFCs are a place to store data and functionality.  Form data, 99% of the time, should be stored in an object or objects. I validate object properties at set time - the object property is set if it passes validation or is not set (if validation fails).  If validation fails, an error message is stored in an array.  In other words, my objects all inherit from a master object that has setProp() and getProp() methods for getting and setting property values.  Within any child object I can define any validation it requires.  When setProp() is called, the object looks for validation rules for that property and performs a validation check if found.  There's a complex series of private methods for doing validation and storing, retrieving, and managing an array of validation failure exception messages for the object.  There's also a validate() method that validates all properties in the object (simply by looking to see if an exceptions exist.  The setProp(), in addition to performing validation, setting a property/recording an exception, also removes validation exception messages upon succussful validation.  It is a flexible and powerful way for all of my objects to inherit the ability to perform validation and to keep all of their data private and control access to that data.  There's going to be an article (and code) about this and a few other very useful techniques I've implemented in the April isse of CFDJ.  Among those other techniques is a generic recordset navigation object I wrote some time ago for the application I'm currently working on. Speaking of CFDJ, the April issue is focussing on architecture - any of you with the desire to write about something related to architecture, whether it's a tip or technique or a full-blown design pattern implementation, feel free to send me an email off list.

~Simon

Simon Horwith
CIO, AboutWeb - http://www.aboutweb.com
Editor-in-Chief, ColdFusion Developers Journal
Member of Team Macromedia
Macromedia Certified Master Instructor
Blog - http://www.horwith.com



GroupOne Dev. wrote:
Simon -

While I agree with you that validating an object vs. validating form data are completely different, why would you ever have an invalid object that needs validating?  Should the data be validated (via the form data validator) before the data is passed to the object's constructor or setter methods?   The only 'link' between a form data validator object and a business object is the fact that the form validator object knows to look for and validate the certain data fields that then go into that business object.

-- Jeff


From: Simon Horwith <[EMAIL PROTECTED]>
Sent: Tuesday, March 08, 2005 4:01 PM
To: [email protected]
Subject: Re: [CFCDev] Is Decorator What I Need or Just Extends?


I don't like this idea of "form validators".  Validation by an object should be performed on other objects.  After all, data collected by a form, if it's used for anything, should be stored in an object somewhere.  The data being collected via a form(s) is still being validated either way, but validating forms and validating objects are very different ideas in the context of the thought process behind how to approach the requirements at hand.

~Simon
Simon Horwith CIO, AboutWeb - http://www.aboutweb.com Editor-in-Chief, ColdFusion Developers Journal Member of Team Macromedia Macromedia Certified Master Instructor Blog - http://www.horwith.com 


Dawson, Michael wrote:
However, a SpecializedFormValidator is a FormValidator.


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of GroupOne Dev.
Sent: Tuesday, March 08, 2005 1:54 PM
To: [email protected]
Subject: re: [CFCDev] Is Decorator What I Need or Just Extends?

I have wondered what the right way to go about this is as well.  However, as a partial answer, I don't believe inheritance or 'extending' an object is the right way.  Inheritance says that a sportsCar object is a specialized car object which is a specialized vehicle object.  A set of validation routines are not specialized versions of anything and thus don't follow an inheritance model.

-- Jeff
---------------------------------------------------------- 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). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
---------------------------------------------------------- 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). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
---------------------------------------------------------- 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). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]

Reply via email to