That's excellent Irv. I think setting the session variable in the loginManagerService is a great solution to your current problem.
As you have seen already, there are a lot of different opinions on the "right" way to work with shared scopes on ColdFusion. The different approaches reflect different opinions on what the problems are that need solving. For me, the biggest issue with shared scopes is that it creates tight coupling. Every part of your code that reads a shared-scope variable can be affected by any other part that sets or deletes the same shared-scope variable. That makes it difficult to test your code in isolation. The ease of changing the scope to use for storing a variable is often cited as a benefit of solutions like scope facades, but in practice I've found this to be a non-issue. In my opinion the most important feature shared by all the approaches suggested here is that they minimize the number of places that knows what shared scope a particular variable lives in. If you can isolate that knowledge to a single CFC, it doesn't matter so much to me whether that CFC is a controller or a service bean, or whether it's for just one shared variable or all of them. PS. I've learned a few things from my mgsecurity project and intend to create a set framework-agnostic components for login/identity management in ColdFusion. These components will return an object containing (among other things) properties for the user ID, real name, and a structure for custom attributes. If and when that's complete I'll integrate it into my mgsecurity project and have the controller drop the identity object into the session scope. I have no idea when I'll get around to this, but if it interests you feel free to bug me about it periodically :-) Cheers, -- Dennis On Thu, Aug 5, 2010 at 1:30 PM, Irv Wilson <[email protected]> wrote: > This morning I ended up thinking a bit more and put the necessary > pieces in the loginsessionmanager of Dennis Clark's (changed) security > example. Since this one object deals with all login/logout stuff I > just added set session.memberID to the login section and then added a > new query method to the same object that retrieves the membersid (or > zero). Seems this will work fine as it keeps all login stuff in one > place. It is mixing CF's login tags with another item > (session.membersid) but they're so closely related I think it'll be > ok. Plus at least now I'll have one spot to deal with the membersid > should I have to change anything. It seems that was a big part of the > posts above. > > Thanks again everyone for the help/ideas. We'll see how this goes. > > -- Model-Glue Sites: Home Page: http://www.model-glue.com Documentation: http://docs.model-glue.com Bug Tracker: http://bugs.model-glue.com Blog: http://www.model-glue.com/blog You received this message because you are subscribed to the Google Groups "model-glue" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en
