Larry-
I just coded that up as an example. What really gets done is.
onAppStart() {
application.dsu = "myDBUser";
...etc...
}
onRequestStart() {
Request.App = Duplicate(Application);
}
So, these vars are really in App scope and then a reference is made to them
and put in Request.App. The person who came up with this method thought
about encapsulation to some degree. I asked him, if you are going down this
route, why not just refer to the app scope directly in your queries, why
make the reference to request scope and use that? His response: "well, down
the line, lets say we want our DSN parameters to come from some arbitrary
place, not be driven from the app scope global var. In that case at runtime
or where necesary just over-write the Request.App struct with the
appropriate values."
To a degree its a facade, which *does* allow more flexibility than just
referring to App scope directly. But I think nonetheless the whole idea is
flawed. I think "RADEMAKERS Tanguy" post pretty much summed it all up.
But one can make the argument:
1) If you know for a fact you will never be redistributing your app outside
your org into a potential different environment...
2) You now for a fact you will never need to use more than DB in a single
"request" or business process..
3) Then you can probably safely get away with using a global scope.
If #1 and #2 are not solid facts you would bet your kids on, then its
probably safer to use encapsulation and pass a DSN struct into each CFC that
needs it in its init() method.
/Cody
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Lyons, Larry
Sent: Wednesday, March 22, 2006 10:48 AM
To: '[email protected]'
Subject: RE: [CFCDev] Storing DSN parameters in a "global" variable
Cody ,
I typically set the DSN and similar params in a "global" variable. However,
one thing to consider when storing DSN parameters is do these parameters
change all that often? If not then why place these variables in the request
scope? By setting these params in the Request scope you set it and reset it
for each and every page request. It would seem to me that the application
scope is more appropriate for parameters that rarely, if ever change.
Here's how I handle these params, using your example:
<cfif not structKeyExists(application,"DSNParams")>
<cflock name="appParamsLock" throwontimeout="yes" timeout="60"
type="exclusive">
<cfset application.DSNParams = structNew()>
<cfset application.DSNParams.DSP = "myDBPassword">
<cfset application.DSNParams.DSN = "myDSN">
<cfset application.DSNParams.DST = "ODBC">
</cflock>
</cfif>
Then later on in deepest darkest Code land:
<cfquery name="foobar"
datasource="#application.DSNParams.DSN#"
username="#application.DSNParams.DSU#"
password="#application.DSNParams.DSP"
type="#application.DSNParams.DST#">
select Dunno
from whoCares
where apathy = "true"
</cfquery>
hth,
larry
--
Larry C. Lyons
Web Analyst
BEI Resources
American Type Culture Collection
email: llyons(at)atcc(dot)org
tel: 703.365.2700.2678
--
> -----Original Message-----
> From: Cody Caughlan [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 22, 2006 12:53 PM
> To: [email protected]
> Subject: [CFCDev] Storing DSN parameters in a "global" variable
>
>
> Is there anything inherently wrong with storing your DSN parameters in
> a Request-scoped structure and referring to these in your cfquerys,
> e.g.:
>
> <!--- pseudo-code --->
> App.cfc::onRequestStart() {
> Request.DSU = "myDBUser";
> Request.DSP = "myDBPassword";
> Request.DSN = "myDSN";
> Request.DST = "ODBC";
> }
>
> .... later, in some code deep in your app...
>
> <cfquery name="foobar" datasource="#Request.DSN#"
> username="#Request.DSU#" password="#Request.DSP" type="#Request.DST#">
> ....
> </cfquery>
>
>
> Apart from the encapsulation this *does not* give you, is there
> anything wrong with this? That is, your code is now tied to the
> Request scope. I
> *know* it would be much better to pass every DSN struct into your CFC
> that needs it (possibly using some kind of a centralized object
> factory like ColdSpring). 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. My argument is that its not "proper
> coding", his argument is the magnitude of convenience this affords.
>
> Whats the right answer?
>
> Thanks
> /Cody
>
>
>
>
> ----------------------------------------------------------
> 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]
>
>
This electronic communication, together with any attachments, may contain
information that is legally privileged, confidential or otherwise private.
The information is intended only for the use of the individual or entity to
which it is addressed. If you are not the intended recipient, please be
aware that any disclosure, copying, distribution or use of the contents of
this communication or any attachment is strictly prohibited. If you have
received this communication in error, please immediately notify the original
sender and delete the received information from your system. Thank you.
----------------------------------------------------------
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]
