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]
