Cody,
>> Using the generic approach, your main add() method would be littered
with >>an IF or SWITCH statement to handle this kind of "one-off"
property >>handling.
You are absolutely right. I am beginning to see weaknesses with
"one-off" or generic handling (ie add()) . I now have a situation where
I did this add('age',30) and I will have to validate age before I pass
the objFilter into my business object.
Thanks for the link too.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Cody Caughlan
Sent: Thursday, January 19, 2006 11:45 AM
To: [email protected]
Subject: RE: [CFCDev] Bean and CFC question
I seem to remember this subject coming up on this list before....search
the
archives?
I am not a fan of this approach. As Larry Wall (creator of Perl) once
said,
"All programmers are lazy", we are always looking for shortcuts. "Hey, I
am
tired of writing stupid getters/setters!". And then an awesome tool like
Rooibos Generator comes along and saves you HOURS of tedious
getter/setter
writing. Add a new property to an existing object is very easy with this
tool.
By encapsulating each property access in its own method(s) you have more
control over how the object handles the internals. For some of my
objects a
basic setFoo() actually does more than a basic assignment, I do some
internal calculations. Using the generic approach, your main add()
method
would be littered with an IF or SWITCH statement to handle this kind of
"one-off" property handling. Eventually it would get tedious,
error-prone
and in-efficient.
Its better to keep it all separate and use a 3rd party tool to generate
the
tedious cool for you.
Rooibos Generator:
http://rooibos.maestropublishing.com/
/Cody
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
Of Nick Han
Sent: Thursday, January 19, 2006 10:22 AM
To: [email protected]
Subject: [CFCDev] Bean and CFC question
I like the use of beans as a bridge to transport data between the
presentation layer (forms) and business objects, which do all the
database
interactions. Constructing beans can be a repetitive and time-consuming
task, so lately I have been toying around with a different transfer
object
that acts like a bean, but it is easier to build, add on, and maintain.
I
would like your opinions on it and whether it is a good or bad.
Instead of writing a bean that has getters and setters and will
interface
like this:
<cfset objFilter=CreateObject("component","reportFilter").init(dsn)>
Method #1
<cfset objFilter.setFirstname="John">
<cfset objFilter.setLastName="Doe">
I then pass this objFilter into my business object. Inside the business
object, the values in the filter object will be accessed like this:
Arguments.objFilter.getFirstName();
Arguments.objFilter.getLastName();
Method #2
I have been toying with this method:
<cfset objFilter.add('firstname','John')>
<cfset objFilter.add('lastname','Doe')>
Inside my business object, I would access the values of the objFilter
like
this:
Arguments.objFilter.getValue('lastName')
Arguments.objFilter.getValue('firstname')
The advantage I see in Method 2 is that as the business object requires
additional filter parameters, the objFilter object doesn't require the
maintenance of adding more getters or setters.
Any thought on the good or bad on Method #2 is appreciated. Thanks.
----------------------------------------------------------
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]