OO technique, but with CFCs the lines are blurred. I had similar text in
there almost verbatim, but took it back out.
For instance, simple CFC-based web services are necessarily of this nature.
Extracting reusable bits and pieces our of non-OO CF app into CFCs as a
first step is another prime example (and one that I've used with great
success when working with a couple large apps that we moved from CF4.5 to
CFMX last year).
Cheers,
barneyb
> -----Original Message-----
> From: Nathan Strutz [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 11, 2004 10:17 AM
> To: CF-Talk
> Subject: RE: Session Variables in CFCs
>
> Thanks Barney,
>
> To continue on what you said, "not every CFC is fully
> encapsulated", this is
> using a CFC as more of a function library than an object in
> an OO world. Not
> "best practices" as far as OO methods go, but still a fair
> use for a CFC
> just to abstract a certain job.
>
> Back to Merritt, I can easily set a session variable in a CFC
> just using
> <cfset session.foo = "bar">. I'll send you some sample code
> if you need to
> see it work.
>
> -nathan
>
>
> -----Original Message-----
> From: Barney Boisvert [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 11, 2004 11:02 AM
> To: CF-Talk
> Subject: RE: Session Variables in CFCs
>
>
> If you have a fully encapsulated CFC it should be unaware of it's
> environment in any way. Since the session scope is part of the CF
> environment, CFCs shouldn't know about it. Generally the
> better route is
> to
> put the entire CFC in the session scope, and have the CFC
> only manupulate
> instance variable (which are also in the session scope,
> because the whole
> CFC is). That way the CFC doesn't need to know about the various CF
> scopes.
> This same thing applies to the application and server
> scopes as well.
>
> Now, not every CFC is fully encapsulated. If you have a
> CFC who's task is
> to manage authentication, it's almost required to set
> session (or client)
> variables. The difference is that this CFC is setting the session
> variables
> for OTHER CODE to make use of (possibly CFCs, possibly
> not). It's not
> setting them for IT'S INTERNAL USE.
>
> Obviously that's a gross oversimplification of the whole
> situation, but
> hopefully helps.
>
> Cheers,
> barneyb
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
