My thinking was that isLoggedIn was a property of the User object. The user is or is not logged in. In my presentation logic, I would check that property of the User object in order to make decisions about what to display.
In actual production, I probably wouldn't use an "isLoggedIn" property, but rather some sort of description about what type of User the user is (what role they are in maybe - except that I find Hal Helm's arguments in favor of permissions over roles very persuasive).
This seems, to me, to be part of business logic. I am not yet making any decisions about presentation. I am instead trying to use my Security object set properties of the User object.
I realize that it is a little odd for a Security object to set properties of a User object (and I am certainly open to changing my ways), but I was thinking in terms of the third umpire from the three umpires story.
-----------------------------------------------
Umpire #1: "I calls 'em as I sees 'em."
Umpire #2: "I calls 'em as they is."
Umpire #3: "They are as I calls 'em."
-----------------------------------------------
Is it not appropriate to set properties of the User object that will later be used in presentation logic? Why is it better to set Session.isAuthorized than Session.User.isLoggedIn (which I was essentially thinking of doing through a method so that my Security object wouldn't have to actually know which properties my User object was using for that sort of thing)?
I guess that I am essentially not understanding why anything in the Session object in inextricably tied to presentation logic. What am I missing?
Thanks!
Steve
At 10:07 AM 4/28/2004 -0700, you wrote:
There's a fundemental separation between different types of logic that I think your missing: business and presentation logic. Business logic is obviously the stuff that makes your application work. Authenticating a user, posting a document, and updating a product inventory, are all business logic. Business logic is independent of the interface, it's purely abstract tasks.
Presentation logic, on the other hand, is exclusively related to the interface your client (be it a person, machine, whatever) is using to talk to the application. This might be a CF/HTML, CFCs/Web Services, Flash Remoting, WAP, whatever. This is the realm where session variables, form validation, and all that fun stuff lives.
So with your validation and session tracking, you've got a piece of both halves. The checkLogin function is pure business logic, but how to handle the result and persist it across requests is presentation logic. By adding the isLoggedIn field to the User CFC, you're trying to make it live on both sides of the fence. It's a business object, so part of the business logic, but integrating it with your session tracking (by making it's behaviour dependant on being cached in a session scope) is tying it to presentation logic as well. That's why I suggested a separate variable for tracking authentication. If you want to store an instance of the User cfc in the session scope, that's great, but don't try to make it help with your authentication/authorization management system, which is undoubtedly tied to the presentation medium.
Business logic is well suited for a high level of abstraction, be it CFCs, Java objects, EJBs, web services, whatever. Presentation logic, on the other hand, isn't as well suited to a high level of abstraction, because it is inherently tied to a specific medium (html, flash, whatever). As soon as you change the medium, the logic probably needs to be changed as well. The trick is to make your presentation layer as lightweight as possible, and to encapsulate as much as you can in your business logic.
Hopefully that all makes sense.
Cheers, barneyb
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Steve Bryant > Sent: Wednesday, April 28, 2004 9:50 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] CFC interaction (user log in) > > I think that makes sense, although I have to confess that I > am still a > little confused. > > Here is what I have: > Security.cfc: > <cffunction name="checkLogin" returntype="boolean" > access="public" output="No"> > <cfargument name="UserID" type="numeric" default="0"> > <cfset var isLoggedIn = false> > <cfif UserID eq 1> > <cfset isLoggedIn = true> > </cfif> > <cfif isLoggedIn> > <cfset Session.User.login()> > </cfif> > <cfreturn isLoggedIn> > </cffunction> > Obviously this won't be the production code. > > User.cfc: > <cffunction name="login" returntype="boolean" > access="package" output="No"> > <cfscript> > this.isLoggedIn = true; > //return this; > </cfscript> > <cfreturn true> > </cffunction> > > If I read this correctly, I should ditch: > <cfset Session.User.login()> > from Security.checkLogin() and take care of that in the code > that calls > Security.cfc? > > The advantage of that would be that each CFC would be more > independent and > therefore more reusable. The disadvantage is that I now have > to have some > logic outside of my CFCs. I guess that I could use a > controller cfm file to > handle that. > > The problem with this (in my mind at least) is that I was > hoping to have > all of my logic in CFCs. It seems that I either have to have CFCs > interacting and less reusable or have some logic outside of the CFCs. > > I am guessing that the answer lies in using a design pattern > that includes > as one aspect to have a CFC whose whole job is to handle interaction > between other CFCs and that I should read the gang of four > book since I > obviously don't know any of this stuff already. > > In fact, I am already convinced that I need to learn design > patterns. The > real question is, do I read the original gang of four book or start > elsewhere? So, I guess I have added another question onto an > email full of > them. > > I really do appreciate the feedback. Sorry it just inspires > me to ask more > questions. =) > > Thanks, > > Steve > > > At 08:36 AM 4/28/2004 -0700, you wrote: > >I think you're pretty close. Your hunch about user.login() > was correct. > >I'd put your login method in your security CFC, since it's not a user > >function, it's a security function that's being performed. > The method would > >return true or false whether the login was successful. If > false, just go > >back to the form. If true, set some marker (I use > session.authenticated) to > >indicate that the session has been authenticated, and do > whatever other > >setup you need (such as instantiating the user cfc into the > session scope). > > > >Always keep in mind that you don't want CFCs interacting > with any scopes > >except their own internal instance variables and arguments passed to > >methods. As soon as you reference any external scope from > within a CFC, > >that CFC instantly becomes much less reusable. However, > it's generally a > >desirable thing to instantiate CFCs INTO shared scopes. > That way all their > >instance variables are, in effect, members of that scope, so > you get caching > >and such. Just be careful with locking and all the usual > concerns with > >shared scopes. > > > >Once you get to doing web services (if you have stateful, > multi-request > >services), then you can reuse everything. You probably > won't be storing a > >user CFC in the session scope, and you might not use the > session scope at > >all, but your checkLogin method in security.cfc will be > identical, you'll > >just deal with the boolean result differently. > > > >Cheers, > >barneyb > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] >
---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
