Home of the ColdFusion Community
|
Mailing Lists
|
Home /
Groups /
ColdFusion Talk (CF-Talk)
CFCs, Application variables, storage location, and CFLOGIN
Author: Raymond Camden
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32166#161480
> And just so I make sure I get this...once I return
> "variables.settings" from that first cfinvoke, it's local to
> that CFC and available thruout the use of that CFC?
Correct. Any method in the CFC can use it.
> Essentially local to that CFC, right?
Yep.
Author: Jeff Small
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32166#161479
> I will try to blog it. I'm out of town on business for the rest of the
week
> (Aspen, poor little ole me) but when I describe it in detail, it will be
> there.
Wow, thanks. I appreciate it.
----- Excess quoted text cut - see Original Post for more -----
Awesome. See? I can "get it"...lol...
----- Excess quoted text cut - see Original Post for more -----
<lightbulb>
wow...that's just...wow...I mean, I TOTALLY see how that works. I even like
the <cfif not IsDefined() bit in there...tight..
</lightbulb>
And just so I make sure I get this...once I return "variables.settings" from
that first cfinvoke, it's local to that CFC and available thruout the use of
that CFC? Essentially local to that CFC, right?
> Well, I'm not sure this is the best (grin), but I like the feel of it
> myself. Note that this method also handles cases where the Application.cfm
> file is NOT run before the CFC is executed.
Yeah, like I said, tight...I like it...
Author: Raymond Camden
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32166#161473
----- Excess quoted text cut - see Original Post for more -----
I will try to blog it. I'm out of town on business for the rest of the week
(Aspen, poor little ole me) but when I describe it in detail, it will be
there.
> somewhere that might explain this a little further? For
> instance, I have a user.cfc that'll perform all the user
> functions (getuser(), adduser(), edituser(), etc) but you're
> saying that I'd build an additional CFC *just* for
> initializing sitewide settings?
Correct.
> How does the application.cfm get these settings, and how do
> the other CFCs get their settings? It's a cart before the
> horse thing, that I'm just not "getting" right now...
Simple. Imagine this is your app.cfm:
<cfif not isDefined("application.settings")>
<cfinvoke component="myapp.settings" method="getSettings"
returnVariable="settings">
<cfset application.settings = settings>
</cfif>
Now imagine another CFC, this would be in your constructor area:
<cfinvoke component="myapp.settings" method="getSettings"
returnVariable="variables.settings">
Then CFC methods could use
datasource="#variables.settings.dsn#"
> I'm just *really* interested in making sure that before I
> even start typing, that I'm setting up everything in the most
> "best practices" way as possible.
Well, I'm not sure this is the best (grin), but I like the feel of it
myself. Note that this method also handles cases where the Application.cfm
file is NOT run before the CFC is executed.
-Ray
Author: Jeff Small
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32166#161467
> Others have chimed in on this thread but I thought I'd comment on
particular
> aspect - the use of Application variables in CFCs. In general, I'd try not
> to do that, as you want to make your CFCs depend as little as possible on
> outside values. I'm not saying to never do it (in fact, I use application
> variables in a CFC I built as a proxy for a Flex app), but to just shy
away
> from it.
>
> What I typically do now is build a settings CFC. This CFC will normally
have
> one method, getSettings(), that returns a struct of stuff like
>
> dsn="foo"
> root="loo"
>
> My Application.cfm will get it's settings by calling the method. My other
> CFCs will get their settings by calling this CFC.
Raymond, I love this idea, but it's a little fuzzy. Is it *possible* that
you can point to a tutorial or an article somewhere that might explain this
a little further? For instance, I have a user.cfc that'll perform all the
user functions (getuser(), adduser(), edituser(), etc) but you're saying
that I'd build an additional CFC *just* for initializing sitewide settings?
How does the application.cfm get these settings, and how do the other CFCs
get their settings? It's a cart before the horse thing, that I'm just not
"getting" right now...
I'm just *really* interested in making sure that before I even start typing,
that I'm setting up everything in the most "best practices" way as possible.
I don't want to do anything "wrong" here...I want to create a full fledged
login/security app and want to eventually move it to a Flash interface, or
make it available to Flash, but for now I just want it to work in CFM.
Author: Raymond Camden
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32166#161462
Others have chimed in on this thread but I thought I'd comment on particular
aspect - the use of Application variables in CFCs. In general, I'd try not
to do that, as you want to make your CFCs depend as little as possible on
outside values. I'm not saying to never do it (in fact, I use application
variables in a CFC I built as a proxy for a Flex app), but to just shy away
from it.
What I typically do now is build a settings CFC. This CFC will normally have
one method, getSettings(), that returns a struct of stuff like
dsn="foo"
root="loo"
My Application.cfm will get it's settings by calling the method. My other
CFCs will get their settings by calling this CFC.
Author: Jeff Small
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32166#161429
> Sounds like a solid plan. If the user.cfc isn't user specific I would
store it in the application scope. Create an init() function so that you can
pass in then dsn, username & password directly from your APPLICATION scope.
So I'd create a function inside my CFC that would initialize these variables
and make them local to the CFC?
> Whatever you do, don't attempt to access the APPLICATION scope from within
the component. It definitely goes against best practice, which I think would
make it worst practice?
But what if all my interactions with the CFC are really thru the form scope?
EG: adduser(), edituser(), deleteuser(), getuser(), loginuser(), etc?
Author: Adrocknaphobia
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32166#161423
Sounds like a solid plan. If the user.cfc isn't user specific I would store it in
teh application scope. Create an init() function so that you can pass in then
dsn, username & password directly from your APPLICATION scope.
Whatever you do, don't attempt to access the APPLICATION scope from within the
component. It definitely goes against best practice, which I think would make it
worst practice?
-adam
----- Excess quoted text cut - see Original Post for more -----
Author: Jeff Small
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32166#161398
I want to redo a login application that I've written with CFLOGIN and
CFLOGINUSER that uses queries in the Application.cfm file. It uses
"application.dsn" as the datasource for the queries.
What I want to do is start using CFCs to move those queries into a
"user.cfc" file Like Ben talks about in the tutorial for CFCs on
Macromedia.com. Put all my user functions into one cfc file.
Now, my questions aren't so much about Syntax, as just general best
practices concerning the where and how. Where, for instance, would you want
to keep this CFC? The only reason I ask is because I was thinking that I'd
still use "application.dsn" which would make it reliant on being in the
scope of the application that I'm writing, at least, I think. That's why I'm
asking. If I have the directory that the root application sits in with an
application.cfm file defining the application.dsn, would that only be
available to the CFC if the CFC sits in that same directory? Is this the way
I should approach this?
Just wondering the best way to set this up before I proceed.
|
May 24, 2012
|
Latest Fusion Authority Articles
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
