I've weighed the various options and for now I like having just one CFC that is aware of the session scope, and have everything go through it, as opposed to having individual methods in different components that access the session. It's a tradeoff, but the centralization and ease of testing or mocking sessions won me over.
On Tue, Apr 29, 2008 at 2:04 PM, Jon Messer <[EMAIL PROTECTED]> wrote: > Aha! So _some_ cfcs can access a shared scope... ;-) > > I actually did shift towards the security service being session aware so > long as it's knowledge of session is self contained a while back, when I > started having flex front ends. But I've also allowed the controller to have > limited knowledge the session and I don't think it's that bad. But it's > definitely not as encapsulated as the other approach. > > In terms of flex I either do what you describe, or have the remote proxy > aware of session or enforce security at the application.onRequestStart > phase, depending on the complexity of the app. > > I knew I didn't totally disagree with you... ;-) > > > > > On Tue, Apr 29, 2008 at 10:48 AM, Brian Kotek <[EMAIL PROTECTED]> wrote: > > > See, you agree with me and don't even realize it. ;-) Your second > > approach would be the one I would recommend. Yes, something, somewhere has > > to know about the session scope or you can't use it. Which is why the > > SessionFacade is the common way to solve the problem. You can encapsulate > > access to the session scope in a single method (i.e. getCurrentUserID() > > would be the only thing that knows about the session scope, and everything > > else calls that method), or you can even create a whole component to > > encapsulate access to the session scope if you're OK with the tradeoffs in > > doing so. > > > > Another issue the choice to enforce security at the Controller level at > > all. What happens when you want to open this up to a Flex application? Or to > > web service calls? Those things never even see your HTML Controller. As > > things go ever more toward SOA, this kind of decision can really cause > > problems later. I'd recommend enforcing such security in the Model as much > > as possible, either through explicit code or via AOP. > > > > That said, of course if your controller has to do something like forward > > the user to a login page (i.e. it is making a decision specific to the HTML > > application), then by all means do so. I'd do something along the lines of: > > > > <cfif not securityService.isUserLoggedIn()> > > <cflocation.../> > > </cfif> > > > > Even in that case, the Controller has no idea *how* the security service > > knows whether the user is logged in or not. For all it cares you're writing > > it to a text file. ;-) > > > > > > > > > > On Tue, Apr 29, 2008 at 1:23 PM, Jon Messer <[EMAIL PROTECTED]> > > wrote: > > > > > I'm not sure I agree with you here Brian, I do agree that for most > > > purposes persistent scopes shouldn't be accessed by objects, but I think > > > session and controller are a little different. > > > > > > Going with the session.userId example, where would the this be set or > > > accessed? > > > > > > It seems to me that if you are going to use the concept of session > > > then either the controller can do something like > > > > > > if(securityService.isUserLoggedIn(session.userId) ) > > > > > > or else the securityService itself would have to know about > > > session.userId. But either way one of these two things has to know about > > > it > > > or else you can't use session at all. > > > > > > I agree 100% that the shared scopes shouldn't be used as a hidden > > > means to pass information to and from objects. And controllers definitely > > > have no business needing a dsn, but if they did it should be passed to > > > them > > > on init not accessed through application. > > > > > > I'm just not sure where you see something like session.userId being > > > set/used. I think of session as a form of user input cached for > > > convienence. > > > And the controller is supposed to mediate user input to/from the model. > > > > > > I could be persuaded I'm wrong though, if you describe how you would > > > handle this situation in a better manner... > > > > > > > > > > > > On Tue, Apr 29, 2008 at 9:54 AM, Brian Kotek <[EMAIL PROTECTED]> > > > wrote: > > > > > > > As the person pushing this in the CF-Talk thread, I have to disagree > > > > with Dan on this one. Though I think he may be misunderstanding the > > > > question. Dan, to be clear, the issue isn't whether it is OK for a > > > > Controller CFC to use values *passed-in* via a method call or > > > > constructor, > > > > which I agree is fine and is in fact the way it should almost always be > > > > done. He's asking whether it is literally OK to directly reference > > > > "application.dsn" or something from within a Controller, which I would > > > > say > > > > no to. > > > > > > > > I don't see any reason why a Controller CFC should need to access > > > > anything in the application or session scopes, or anything external to > > > > the > > > > component for that matter (meaning anything not passed as arguments to > > > > the > > > > method or properties of the component). > > > > > > > > In fact, I'd argue that in most cases, if you think you need to > > > > access an application or session variable from inside a Controller, it > > > > means > > > > you may want to reconsider what the Controller is doing in the first > > > > place. > > > > Things like "application.dsn" or "session.userID" should probably never > > > > be > > > > needed by a Controller. These things are used by the Model, and the > > > > apparent > > > > need for these kinds of values may indicate that your Controller is > > > > doing > > > > work that should really be happening in the Model anyway. My > > > > Controllers are > > > > really, really dumb. All they do make requests to the Model to perform > > > > processing, and render Views. > > > > > > > > regards, > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > On Tue, Apr 29, 2008 at 12:03 PM, Charlie Griefer < > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > Hey all... > > > > > > > > > > I've had a lingering question, and a thread over on cf-talk (about > > > > > properly encapsulating CFC methods) has really got me thinking > > > > > about > > > > > it. > > > > > > > > > > Over on that thread, there's a "debate" (to use the term loosely) > > > > > on > > > > > accessing the application scope from within a CFC. Yes, I > > > > > understand > > > > > that's a "bad thing" and I understand why. But in an MVC > > > > > framework... > > > > > what about CFCs in your controllers? Those CFCs don't really > > > > > model > > > > > any particular object. They're more of a transport mechanism to > > > > > facilitate communication between the model and the view. > > > > > > > > > > So, I get that CFCs in the model should be encapsulated. But what > > > > > about CFCs in the controller? is it "acceptable" (which i realize > > > > > is > > > > > a subjective term) to access shared scopes like application and > > > > > session from controller CFCs? > > > > > > > > > > -- > > > > > Evelyn the dog, having undergone further modification pondered the > > > > > significance of short-person behaviour in pedal depressed, > > > > > pan-chromatic resonance, and other highly ambient domains. "Arf," > > > > > she > > > > > said. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" 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/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
