Also a quick clarification, to do this you don't have to use ColdSpring (you could create the Config CFC yourself and pass it to other CFCs manually). I'm just so spoiled by ColdSpring that I would never build an app without it. ;-)
On 6/7/07, Brian Kotek <[EMAIL PROTECTED]> wrote:
Still no problem. Create a Config CFC (or whatever) to encapsulate this info, have ColdSpring create it and inject it into your other CFCs. Your cfquery calls then call config.getDSN() to determine the DSN name at runtime. Within the Config CFC you can store the actual values in the session scope and that is what it will return. Or the Config CFC could in turn hold a reference to a SessionFacade CFC which handles getting and setting data in the session scope if you prefer to keep all access to the session scope encapsulated in one place. This is probably overkill for one value (the DSN) but usually there is a bunch of Config data (production server may have different paths or other settings than, say, localhost) and once you start dealing with multiple settings or multiple variability of the settings, encapsulating this into its own CFC can be very useful. Hope that helps. Brian On 6/7/07, Phillip Senn <[EMAIL PROTECTED]> wrote: > > I'm on a shared hosting environment (hostmysite.com) which allows only > one database, but multiple sql server _users_. > > So my Datasource name is > 1. DSN (ColdFusion) > 2. UserName (sql server) > 3. Password (sql server) > > So my DSN changes depending upon how you login. > Developers login as one sqlserver user, customers login as the other. > The login table always comes from the production username. > > So I've put my DSN in the session scope, because it could vary depending > upon different sessions. > > In addition, I have other Datasource options that could vary depending > upon the session: > 1. Logging (keeping track of what commands this session has issued). > 2. Error Trapping (on for users, off for developers). > > I'm working on moving my development to my local machine, but in my > early attempts at learning cf, I wanted all development to be done on > the server that would ultimately be the production server. That way if > I ran into any permission problems, it would come out early. > > > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Sammy > Larbi > Sent: Thursday, June 07, 2007 12:43 PM > To: cfcdev@cfczone.org > Subject: Re: [CFCDEV] Application.cfc: where to set DSN > > Hi Joe, > > In my view, a DSN is a variable that properly belongs to an > application. Therefore, I'd go with putting it in onApplicationStart, > since by the very nature of its name, implies that you are setting > variables belonging to the application. > > Others may view it differently, however. > > Sam > > > Joe Lakey wrote, On 6/7/2007 11:03 AM: > > Another newbie question to provide a little light diversion from > > interfaces and method overloading... > > > > My application uses only one DSN, and I'd like to set it in one place. > > I'm cfincluding two files in onRequest(): server_config.cfm, which > sets > > server/environment variables, and app_config.cfm, which sets > > application-specific variables; both set variables in Request scope. > It > > would seem that one of these includes would be the place to set the > DSN, > > i.e., <cfset Request.DSN = "myDSN">. However, in onApplicationStart() > > and onSessionStart() I'm instantiating components that take the DSN as > > an argument to their init() methods. If I understand the sequence that > > > Application.cfc methods are executed, onApplicationStart() and > > onSessionStart() won't have access to variables set in onRequest(). So > > if I want to set the DSN in only one place, where is the best place to > > > do it? > > > > It's probably obvious (and there's probably a better way to architect > > the whole app to avoid this, but...), but I'm still getting my mind > > around this OO stuff. > > > > Thanks, > > Joe > > > > > > You are subscribed to cfcdev. To unsubscribe, please follow the > instructions at http://www.cfczone.org/listserv.cfm > > > > CFCDev is supported by: > > Katapult Media, Inc. > > We are cool code geeks looking for fun projects to rock! > > www.katapultmedia.com > > > > An archive of the CFCDev list is available at > www.mail-archive.com/cfcdev@cfczone.org > > > > > > > > > > > > You are subscribed to cfcdev. To unsubscribe, please follow the > instructions at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/cfcdev@cfczone.org > > > > You are subscribed to cfcdev. To unsubscribe, please follow the > instructions at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/cfcdev@cfczone.org > >
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
