Ah, I suppose that makes some sense if your validate returns complex messages. Generally my validate methods return one error, the first that is found, so it would be a simple thing that can then be thrown back to the user. Now, I do take exception with
"> textual error messages to return to the calling code. That > also keeps the messages (which are really part of the > presentation layer) separate from the logic." I assume you mean this if your validate is returning a set of messages? ======================================================================== === Raymond Camden, ColdFusion Jedi Master for Mindseye, Inc (www.mindseye.com) Member of Team Macromedia (http://www.macromedia.com/go/teammacromedia) Email : [EMAIL PROTECTED] Blog : www.camdenfamily.com/morpheus/blog Yahoo IM : morpheus "My ally is the Force, and a powerful ally it is." - Yoda > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert > Sent: Monday, October 06, 2003 1:03 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Data validation > > > I'm not saying that 'store' shouldn't validate, it DEFINITELY > should, what I am saying is that 'store' shouldn't care about > how the validation process works. In Andy's original post, > he said that 'store' would throw an exception if 'validate' > wasn't called first, and that's totally wrong. It creates a > very tight coupling between the 'validate' and 'store' > methods, which are relatively unrelated in terms of the > public API of the object. > > Here is a perfectly legit implementation of the 'store' > method, using validate, though it is definitely less > effecient than it could be: > > <cffunction name="store" ...> > <!--- arguments ---> > > <cfif structCount(validate())> > <cfthrow type="InvalidStateException" /> > <cfelse> > <!--- do the store ---> > </cfif> > </cffunction> > > A better route is probably to have a private method that > returns a bitmap or something indicating which validation > errors that both 'validate' and 'store' will call. Store > will just look and see if it's non-zero, while validate will > unmap (is that the right term) the bits, and convert them to > textual error messages to return to the calling code. That > also keeps the messages (which are really part of the > presentation layer) separate from the logic. > > barneyb > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of Raymond Camden > > Sent: Monday, October 06, 2003 11:52 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] Data validation > > > > > > This is an interesting view, Barney, more so because it > seems wrong to > > me. Why would it not be the domain of "store" to also do a > validate? > > Consider a Person CFC, which has an age property. The age must be a > > number greater or equal to zero, but less then 150 (or some > such). Why > > would "store" want to assume that you passed it valid data? Sure it > > can validate (using <cfargument>) that the value was a > number, but it > > can't validate that it's a "proper" number. I guess it > comes down to - > > why do you assume the caller will send you proper data? You say > > validate is a tool to help the calling code - and I agree > with that - > > but why can't it help other methods as well? I can > certainly see the > > client calling > > validate() to ensure the data it wants to pass to store() > is safe, but > > I'd assume store() would assume the user is always > forgetful, and should > > therefore do the anal thing and validate() as well. > > > > > ====================================================================== > > == > > === > > Raymond Camden, ColdFusion Jedi Master for Mindseye, Inc > > (www.mindseye.com) > > Member of Team Macromedia > (http://www.macromedia.com/go/teammacromedia) > > > > Email : [EMAIL PROTECTED] > > Blog : www.camdenfamily.com/morpheus/blog > > Yahoo IM : morpheus > > > > "My ally is the Force, and a powerful ally it is." - Yoda > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > > > Behalf Of Barney Boisvert > > > Sent: Monday, October 06, 2003 11:52 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [CFCDev] Data validation > > > > > > > > > I would highly recommend that your 'store' method does > NOT through > > > an exception unless there is a problem. Having it check > to see if > > > 'validate' was called is not it's job. It's job is to merely > > > disallow the operation if it can't proceed, and whether > 'validate' > > > was called has no bearing on that. 'validate' is a tool > to help the > > > calling code determine what an exception means in a way that can > > > help it be resolved. > > > > > > You want me to structure my code this way (which is perfectly > > > legit): > > > > > > <cfset errors = myCFC.validate() /> > > > <cfif structCount(errors) GT 0> > > > <!--- error display ---> > > > <cfelse> > > > <cfset myCFC.store() /> > > > </cfif> > > > > > > But I like to do it this way, since we have an exception handling > > > mechanism in CF. It just reads cleaner than a bunch of > CFIFs that > > > are doing exception handling. And in this case, it'll > also save me > > > from generating that error struct unless I need it. > > > > > > <cftry> > > > <cfset myCFC.store() /> > > > <cfcatch type="IllegalStateException"> > > > <cfset errors = myCFC.validate() /> > > > <!--- error display ---> > > > </cfcatch> > > > </cftry> > > > > > > > > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email to > > [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in > the message > > of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > by Mindtool, Corporation (www.mindtool.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 word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.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 word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
