thanks for all the feedback.
________________________________
From: Kola Oyedeji [mailto:[EMAIL PROTECTED]
Sent: Friday, June 18, 2004 10:17 AM
To: CF-Talk
Subject: RE: request scope in cfc... really so bad?
Simon
Generally its good for your cfc to be well encapsulated such
that it
doesn't know anything about its environment. This will make it
more
re-useable. Consider this - what happens if you need to call the
cfc as
a web service in future you've just lost that flexibility. If
you have
no plans to do this and you know that these variables will
always be
available in *every application* you write then its not a
problem. But
if you plan to re-use it I would pass the variables in, remember
you can
put them in a structure and pass them into an initialization
function
using attributesCollection (I think) although you loose the type
checking of cfarguement.
Hope that helps
Kola
-----Original Message-----
From: Simon Stanlake [mailto:[EMAIL PROTECTED]
Sent: 18 June 2004 17:59
To: CF-Talk
Subject: RE: request scope in cfc... really so bad?
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]
