yep, though I guess my question is really, why not use request scope,
rather than how to work around it. There are probably lots of ways to do
it without using request scope, but request seems like the least
overhead.

________________________________

From: Barney Boisvert [mailto:[EMAIL PROTECTED]
Sent: Friday, June 18, 2004 9:36 AM
To: CF-Talk
Subject: RE: request scope in cfc... really so bad?


Why not make a configuration CFC (basically an encapsulated
struct), that
you can pass to all the various CFCs?  Instantiate that CFC into
the
application scope, initialize it with the parameters, and then
pass that
single course-grained view of the configuration data to each
individual CFC
that needs it.

Cheers,
barneyb

> -----Original Message-----
> From: Simon Stanlake [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 18, 2004 9:29 AM
> To: CF-Talk
> Subject: request scope in cfc... really so bad?
>
> Thoughts?
>
> If CFCs were EJBs, you would have external config info that
you would
> look up using JNDI (or something, I'm not quite up to snuff on
J2EE).
> Let's say I am careful and create well named variables like...
>
> request.<cfcname>.datasource = "MyDatasource";
> request.<cfcname>.timeout = 300;
>
> etc, all in one file called <cfcname>.cfm that is included in
> application.cfm. Contract with the developer is you have to
include
> <cfcname>.cfm in your application.cfm before calling the CFC.
> Am I such
> a bad guy?
>
> I guess worst case scenario is Macromedia decides not to
> support it one
> day, but I haven't heard anything about that. It's just such a
pain if
> there's 10 variables in your app that are required by 10
> different CFCs,
> passing them in as args to the constructor seems awkward.
>
>
________________________________
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]

Reply via email to