>I have a fellow developer who prefers this
>"global" approach. I say its bad, he says
>its OK, because Macromedia (now Adobe) will
>never take away the the REQUEST structure,
>so its not like the code will ever break.
It doesn't just rely on a request scope, it relies on a request scope
that looks a lot like your request scope (in terms of structure key
names, meaning, etc).
1) Imagine you are sending your object to a friend at another company
(or a customer, or an open source project or whatever - you are
distributing it).
His way: you have to tell people all kinds of extra information about
how to set up the environment to make sure that the code runs - worse,
you have to REMEMBER all this stuff (or look it up in the code)... when
was the last time you changed the definition of Request.DSU?
Your way: inspect the component in the cfc viewer. All required
information in black on white.
2) You set up a second database and dsn - some object will have to be
switched to use that
His way: open up the objects and change:
<cfquery name="foobar" datasource="#Request.DSN#"
username="#Request.DSU#" password="#Request.DSP" type="#Request.DST#">
to:
<cfquery name="foobar" datasource="#Request.DSN2#"
username="#Request.DSU2#" password="#Request.DSP2"
type="#Request.DST2#">
Your way: declare a new struct in the App.cfc and pass that in to the
objects that target the new database/dsn. Change in object code: 0 lines
>My argument is that its not "proper coding",
>his argument is the magnitude of convenience
>this affords.
His way basically saves you two minutes today at the cost of two hours
six months from now. Remember: there's never time to do it right, but
there's always time to do it over.
/t
----------------------------------------------------------
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]
