I went down this road (I'll post some code in a bit) because I had a "user"
CFC that had 50 (or thereabouts) properties (name pieces, address pieces,
email, IM, etc).

All of those properties were "simple" gets (just return the property).  Most
of the properties were simple sets (just the set the property - but I still
wanted to check for type) except (at the time) email addresses - I wanted to
do validation on the format.

Now I could have written 100 methods for getting/setting.  Instead I figured
it all out and did a generic setter/getter.

The generic methods leverage several custom metadata methods and require you
to build components in a specific way (there's really no way around that)
but it's very easy.

The Generic methods:

1) First verify that the passed property has been defined in the CFC (or in
an ancestor).  If not an error is thrown ("Property not defined").

2) Second they check to see if a specific getter/setter has been defined (in
the format "getPropertyName" or "setPropertyName").  If it has been they
pass the arguments to that and return what it returns.

3a) The getter, at this point, check to see if the property has been
initialized (defined).  If not an error is thrown, if so the property is
returned.

3b) The setter checks the metadata to get the type of the property (Boolean,
string, etc).  It then checks the type using a custom method I wrote that
can accept the same types as CFARGUMENT.  And error is thrown if the value
is of the wrong type.

4) If everything goes well until now the generic setter writes the property.

This whole scheme could be changed (very easily) to also write "ad hoc"
properties (properties not defined in the meta data) but since you would
lose type validation I didn't do it that way.

Using this, in the end, I was able to write a private
"validatePhoneNumber()" method and create specific setters for the phone
number properties that basically just did this (pseudo-code!):

setPhonePrimary() {

        validatePhoneNumber(arguments.Phone);
        setProp("PhonePrimary", arguments.Phone);

}

So even when I have to write a specific setter/getter it's often cleaner to
just do the validation you want then let the generic method do the gross
type validation, check the metadata and so forth.

But the big win was that I only had to write a few setters for the phone
number properties and not all 100.

Jim Davis

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Joe Rinehart
> Sent: Monday, August 02, 2004 9:29 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [CFCDev] Comment requests CFC instance vars
> 
> Hi Jim,
> 
> How would you go about doing this?  I sorta disclaimed my post with
> "unless the setter calls the appropriate property-specific setter"
> piece...I assume that's what you're talking about doing?
> 
> I've been required to provide these methods before, and implemented
> them by making sure set#arguments.propertyName# and
> get#arguments.propertyName# existed, were functions, and then calling
> them appropriately.  But at that point, why use the generics?
> 
> -joe




----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words '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]

Reply via email to