Just
to chip in my thoughts at this late stage of the thread....
I am
using a kind of generic bean method:
Each
of my objects holds an array of field
definitions, and to get a bean, you ask the object for a
bean.
the
getBean() function only accepts one argument, a struct. The object then loops
through its fields and populates the bean with any fields found by name in the
struct, if the field is not present in the passed struct, the object puts in the
default value for that field (if there is one, else no
value).
The
bean does no validation/type checking at all, and simply holds a set of values,
but it will not accept a field that shouldnt be there, unlike a method of
setValue(valname,value), so in essence, the interface to the bean is generic,
but the bean itself is not.
Regarding how it performs:
I have
one site built on this framework that gets over 30,000 unique
sessions per month, which isnt a massive amount, but I wouldnt consider it
a small amount.
The
page render time is usually between 50-150ms.
CPU is
sitting around 0-2% and spiking to 20-30%
mem
usage is about 25%
-----Original Message-----
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of
Peter J. Farrell
Sent: 11 May 2005 05:34
To:
[email protected]
Subject: Re: [CFCDev] Generic Beans (was: LTOs
(was: Form Validation))
Dave Merrill wrote:
What do you think about generic setValue(value_name, value, expected_type)
and getValue(value_name) methods?
A bean explicitly maps out it's purpose. Using a
generic type bean moves the uniqueness as well as the responsibility of that
object into the calling code. A generic bean is no longer a discrete
object and no longer represents the true nature of your mode. If I
received legacy code like this, I would have to look through thousands of
lines of code just to see what what this generic bean is doing instead of
firing up the cfc explorer to see what it actually does.
I have a
generic errorHandler which uses setError(errorCode, settingObj, fieldName),
getError(errorCode), hasError(errorCode) and etc. This is a great way to
use generics as I couldn't possibly have all the possible accessors for the
errors in my application in the errorHandler. The setting object
controls the error codes getting set and thus has the responsibility of the
errorHandler. I usually pass in an init()'ed errorHandler on my bean's
validate method, pass it back out, call hasErrors() [boolean] and either send
the bean on or repopulate my form with the errors [my errorHandler only has
error codes - the errorMessage class takes care of translating the codes into
things more user friendly - this separates the actually user message from the
model and into an object more akin to a special "View"].
I'd see a lot of benefit to individual set/get methods if we were in
compiler-land, where the calling a nonexistent method was a compile-time
showstopper rather than the run-time error it is in cf. It would be much
harder to ship code that was broken on that level. But since that's not
current cf reality, IMO it's much harder to justify the purpose of each
identical basic getter and setter.
True, it would be hard to ship code that is broken.
I honestly believe that is there was a better way than using getters/setters
it would have made them a "legacy" method of OO programming by now.
I
have three goals when I code:
1. Write code that accomplishes what is
supposed to accomplish in the most efficient and concise manner.
2.
Write code that shows/demonstrates its' exact purpose by using best practices
and precisely written comments/hints.
3. Write code that could be
easily maintained by someone other than myself.
I think that a generic
bean would be hard to maintain citing that "generic makes it generic" - it no
longer explicitly shows its' purpose in your model and moves the identifying
parts of your bean into the calling code. Secondly, your bean will have
to spend more time resolving arguments and less time doing what it supposed to
do. I find this to be an unnecessary waste of processing time. The
actually savings are probably hard to prove - but I'm sure an application
under heavy load would show it more.
To quote Bill Rawlinson: "Don't
let seeming redundancy and tedium turn you away from using discrete objects to
represent your model." I'm glad that you are challenging your
programming skills and exploring other options as that is the only way to keep
things moving forward instead of stagnant - otherwise we'd be programming in
ColdFortran!
Best,
.Peter
P.s. For anybody who has programmed
Fortran...luckily my exposure is limited to my father's Fortran programming in
the 70's.
"GOD is REAL (unless declared INTEGER)."
--
Peter J. Farrell :: Maestro Publishing
blog :: http://blog.maestropublishing.com
email :: [EMAIL PROTECTED]
Create boilerplate beans!
Check out the Mach-II Bean Creator - free download.
http://blog.maestropublishing.com/mach-ii_beaner.htm
Fatal Windows Error 039: Cray not found - System Halted.
--
----------------------------------------------------------
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).
CFCDev is supported by New Atlanta, makers of
BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An
archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------