I agree with Nathan. I have something like this in my global settings file,
repeated a couple times for different CFCs:
application.securityService = createObject("cfc",
"com.myapp.securityservice");
application.securityService.init(application.dsn,
application.objectCacheDir);
Those CFCs provide set of interfaces to my model (implmemented by more CFCs)
and then to my database. All the CFCs are stateful, and all are constructed
(using the init() method) with the datasource name. I've found it works
very well, and since the DSN is always there as an instance variable, I
never have to worry about passing the same variables all over my
application.
---
Barney Boisvert, Senior Development Engineer
AudienceCentral
[EMAIL PROTECTED]
voice : 360.756.8080 x12
fax : 360.647.5351
www.audiencecentral.com
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Nathan Dintenfass
> Sent: Thursday, July 31, 2003 3:59 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFCDev] envronment variables and CFCs
>
>
> Of the options you outline #1 and #2 are probably your best bets. Keep in
> mind for #1 it need not be so ugly -- particularly if you cache these CFC
> instances you can pass in the "global variables" only once when you init.
> You could also pass in a struct using ArgumentCollection (or just as a
> single argument) there, so it could really be quite elegant in your code
> that uses the CFC. If you have a single instance of your
> components in the
> Application (or Server) scope you can code a few lines in Application.cfm
> and then go on your merry way without thinking about such things
> ever again.
>
> Option #3 is a bad idea because it breaks the (good) advice of making
> extends used only for an "is a" relationship -- which it doesn't
> sound like
> you'd have here.
>
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Behalf Of Matthew Walker
> > Sent: Thursday, July 31, 2003 3:50 PM
> > To: [EMAIL PROTECTED]
> > Subject: [CFCDev] envronment variables and CFCs
> >
> >
> > Hiya,
> >
> > We have a bunch of fairly amateurishly written CFCs (yes guilty)
> > that access
> > a few global environment variables in the request scope (say for example
> > datasource name and a few similar). Now I'm trying to address this and
> > finding I have a few options....
> >
> > 0) Access environment variables in the request scope directly
> from the CFC
> > method. This is the technique I'm undoing, hence option 0.
> >
> > 1) pass each environment variable into each CFC method as
> > required. I think
> > this is an ugly inelegant solution although conceptually the simplest.
> >
> > 2) Create an object containing all the environment variables
> with accessor
> > and mutator methods as appropriate and pass in this object when
> > initializing
> > any CFC. This is the option I'm in favour of.
> >
> > 3) Have each CFC extend a CFC that can access these environment
> > variables. I
> > am uncomfortable with this as it seems like the name space of the CFC is
> > going to be rather crowded with methods -- there'd be
> > getSomethingVerySpecificToThisObject() alongside
> getSomeAppSetting() which
> > seems disorganized.
> >
> > Other options? No doubt. This must be a very common, very fundamental
> > problem. What do other folks do?
> >
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email
> to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
> in the message of the email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported
> by Mindtool, Corporation (www.mindtool.com).
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.504 / Virus Database: 302 - Release Date: 7/24/2003
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
