Hi Irv, You're definitely on the right track.
What you've stumbled upon is one of those situations that spawns endless debate over the "best" way to do things. What I've written below is my personal opinion but various closely-related forms of it is used by lots of other people. The idea behind the sessionFacade or scopeFacade is to hide away the implementation of WHERE you're putting the login id and other information (I'll share my opinion on naming that object in a bit). Functionally, putting a call to the session scope in your controller will work if a lot of situations. However, what if your application suddenly needs to scale to N number of servers behind a load balancer and you no longer want to store that ID in the session scope, but now need to store it in a cookie. You're left with finding all the places in your controllers (and potentially elsewhere) that you've made that direct call and replace it with a call to cookie.whatever. You could do that, but it's not ideal and it introduces a lot of extra risk as you touch each of those files. Now, if you've built an object such as the scopeFacade.cfc you mentioned whose job it is to get and put things to the session scope and all your controllers use scopeFacade.getLoginID() to retrieve it, you simply have to update the contents of the getLoginID() method in that object to change from session to cookie and your entire application now has been updated for that new environment. Similarly, you've not touched the code in all those controllers so the risk of you breaking something with that change due to copy/paste errors or typos has gone down significantly. With ModelGlue's bean injection features, you can easily drop that facade cfc into your controllers using the beans='object1,object2' attribute on the cfcomponent tag so it makes it super simple to auto include that facade cfc into your controller (see http://docs.model-glue.com/wiki/HowTos/HowToUseBeanInjection#BeanInjection if you're not familiar with that). You mentioned that Ray Camden named his facade object scopeFacade.cfc. Like you, I've seen a lot of people name it SessionFacade.cfc (and I've done it in the past myself). There's no harm in naming it SessionFacade.cfc even if later you change the internal workings of it to use the client scope rather than the session scope. The reason I like Ray's naming choice on that is that it's generic enough to be applicable no matter if you're using session, cookie, client or whatever scopes while, if a new person to your application looks at the code base and sees a component named SessionFacade.cfc he/she will most usually assume that whatever is going on in there utilizes the session scope and that might not be correct. So, if I haven't bored you to death yet, the bottom line is keep on keeping on the route you're going. The facade pattern that these objects we're talking about is based on has a definite use case and solves a specific set of problems (in this case polluting the rest of your code with hard coded scope references). Learning when and how to use design patterns to correctly solve certain problems is something I'm still working on myself, but in the end, it's worth the headaches, failed code snippets and asking questions to get your arms around these things and you'll be a better developer for the effort. Please don't hesitate to fire off more questions as you're working through things. Best wishes, Dan On Aug 4, 2010, at 10:43 PM, Irv Wilson wrote: > I've set up several existing mg app examples > (quickstart,plantomatic,DC's mg security) plus butchered a couple > examples of my own (one live - bodygeek.com) in order to learn mg. > > The problem I'm having is I took mg_security example, got rid of > cfscript, hooked to mssql for login info, and everything in example > works fine. Being this uses cflogin I have username easily available > after login but I need userID. In my simple mind I would set > session.userID at login and retrieve it in controller to pass to > model. Everywhere I read, though, that is a big "no no". So.... I've > spent over a day looking at various ways to set and get access to this > one session var properly and I'm thoroughly frustrated. > > I see Ray Camden made something called a scope facade for canvas which > I've sort of been able to follow. I've read about this approach > elsewhere as well except seems to be mostly called session facade in > other places. His structure, however, uses this for pretty much his > entire authentication routine in canvaswiki and I think canvaswiki is > unity so not sure if anything dated. The one other session facade > routine from 2007 I found online I'm almost certain has an error in it > as written. It simply doesn't make sense as it calls a function it > never defines (or appears to me never defines). Regardless I can't > get that example to work. > > So the question - Is there a "preferred" or "standardized' sort of a > way to accomplish accessing this one session var or small group of > vars in mg? Plantomatic might touch on this but it dives into the ORM > world which I want nothing to do with, at least not yet. > > Thank you to anyone who can shed light! > > Irv > > -- > 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 -- 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
