CFCs, Application variables, storage location, and CFLOGIN

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.

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.

> 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.

----- 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

> 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...

> 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.

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 -----

> 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?