Right on, I think you are going the right direction. Although I'm still unsure if a seperate security.cfc is necessary. Afterall the methods in the security.cfc pertain to only a user. CheckLogin() and login() preform actions for a user. I would put checkLogin() in the user.cfc and in your pages uses <cfif userObj.checkLogin()> for your logic. Or set it directly to a SESSION variable like SESSION.isLoggedIn = userObj.checkLogin().
As far as modularity, if security.cfc relies completely on user.cfc, then security.cfc is not modular at all and might as well be wrapped into the user.cfc. my 2 cents -adam > -----Original Message----- > From: Steve Bryant [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 28, 2004 04:50 PM > 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]
