In that case there as a baseContentObject that contained the basic
machinery -- the "fields" were defined in CFPROPERTY tags in CFCs that
extended the baseContentObject. It was a very "fat object" way of thinking,
and the need to introspect the meta data at run-time proved to be overly
burdensome from an overhead perspective.
That said, the basic concept of having an instance always have an "error
state" could easily be done without the other abstractions.
Basically, it had an array of errors set up on init() -- the hasErrors()
method really just, internally, tested arrayLen(instance.errors);
Then, whenever setting data it would automatically be validated. In that
case, it was based on meta data in the CFPROPERTY tag (each field had a list
of "rules", each of which was a component with a standard interface), but
there's not reason it needs to be that abstracted. In other words, the act
of saying something like:
user.setName("Nathan","Dintenfass");
would automatically validate that data -- if there was something wrong with
it, an "error" (in that case, a CFC instance, but could just as easily be a
struct or even just a string, depending on your implementation) was
generated and appended to the array of errors held internally.
Bottom line: I'm not totally convinced the "error state" method is
necessarily a best practice, though if are already adopting a "fat object"
paradigm it might make for nicer code than the need to manually validate
and/or catch exceptions (which was the original reason for using it -- to
make the API as flexible as possible while maintaining the integrity of the
data).
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Barney Boisvert
> Sent: Monday, October 06, 2003 1:37 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFCDev] Data validation
>
>
> I like that mechanism. Where did you put your validation code?
> 'hasErrors'? If so, didn't you have to duplicate it in 'getErrors'?
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Behalf Of Nathan Dintenfass
> > Sent: Monday, October 06, 2003 12:34 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [CFCDev] Data validation
> >
> >
> > Just to throw another approach into the discussion, one thing I did when
> > building Modus (now defunct) was to have the instance have an
> > error state at
> > all times. I then called my validation method(s) whenever
> > populating data.
> > The end developer code would then look something like:
> >
> > if(NOT obj.hasErrors()){
> > obj.store();
> > }
> > else{
> > errorsToShow = obj.getErrors();
> > }
> >
> > The store() method could then throw an error if hasErrors()
> returns true.
> > Thus, the end API was highly flexible, allowing an application to do
> > whatever it needed to do -- while maintaining the internal
> > integrity of the
> > data (you couldn't commit your changes to the instances if there were
> > errors).
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > Behalf Of Hagan, Ryan Mr (Contractor ACI)
> > > Sent: Monday, October 06, 2003 12:13 PM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: [CFCDev] Data validation
> > >
> > >
> > > I can't say which method (if any) is the "correct" method,
> but I can see
> > > some benefit to having your store() method be a little dumb. I
> > > don't think
> > > that you should "definitely" have store() call validate(). I may have
> > > perfectly legitimate reasons for wanting to serialize "bad"
> > data, such as
> > > storing a "900" year old "person".
> > >
> > > Possibly an even better implementation would be passing your
> > > store() method
> > > an optional parameter (defaulted to true) that indicates
> > whether or not to
> > > call the validate() method?
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Barney Boisvert [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, October 06, 2003 3: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]
> >
> > ----------------------------------------------------------
> > 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]
