Just getValidationErrors(), which creates the error set if needed
(caching it, of course), and returns it.

isValid would be implemented as getValidationErrors().size() EQ 0, and
that's just as easily to put in the calling code, since you'll need
the error set to display the errors, and it might be a compound error
set as we've discussed.  It's a slight over-coupling of the calling
code to the object, but one I'm comfortable with.

I don't have a hasModified either, because it's irrelevant to external
users if an object has been modified.  What's relevant is if the
calling code *thinks* the object has been modified.  I.e. calling a
setter doesn't necessarily change something (i.e. set a field to it's
same value).  The setters null out the validation set when called, of
course, and the object maintains an internal list of properties that
have changed.  Then when a save/update is requested, the object can
tell if it actually needs to run a query on the DB, and what specific
fields need to be included.  That makes for smaller queries, and in
some cases avoid spurrious UPDATE statements all together.

And yes, all this is major implementation details of my persistance
layer.  It's all encapsulated within an abstract superclass that all
my business object derive from.

cheers,
barneyb

On 10/30/05, Scratch <[EMAIL PROTECTED]> wrote:
>
> Makes a lot of sense.
>
> So you probably have something along the lines of these functions in all
> your CFCs:
>
> - isValid(): Checks existence of ErrorSet or ErrorSet.ErrorCount() gt 0
> - hasChanged(): Returns the value of variables.Instance.Modified which gets
> set to TRUE on every setXXX() method?
>
> Baz
>


--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/

Got Gmail? I have 100 invites.


----------------------------------------------------------
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