A few thoughts: I'd think that the "stateful" user component would have methods like:
isStudent() isEmployee() isTeacher() and maybe for convenience things like: isStudentOrTeacher() You'd populate the instance of a User when your user logs in and cache it in their session as something like "session.user". That would let you do some simple if statements on your pages to wrap any content that is intended for each type of user (you might even wrap that in a custom tag to make your code a little nicer). You can then use those same methods to build some simple security mechanism to block certain pages from being accessed (assuming that's necessary). You might have a custom tag called "secure.cfm" that you'll call using the CFIMPORT prefix "auth". You might then have: <auth:secure type="teacher"> at the top of a page that only a teacher can see -- then inside the tag you call session.user.isTeacher() for that type. Of course, your exact implementation will vary depending on your needs, but you get the idea. For Course Info you'll probably want a "stateless" component (I like to think of them as "services") cached in the Application scope -- then you can do something like: application.courseService.getCourseInfo(session.user); Then your "courseService" component can call whatever methods on the user it needs to determine what info it needs to send. Alternatively, you could pass in the specific information (by calling a method on the session.user rather than passing the whole thing in) needed to get course info rather than a whole User instance. For the method getUserGroups(userID) I'd suggest you not make that part of the "stateful" user component. Instead, perhaps have a "UserService" component (again, cached in the Application scope) that takes a user id to get information about a given user. You might even consider having your UserService act like a "Factory" to give you user instances -- but, that's probably more than you need to think about to get started. HTH. - Nathan > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Dawson, Michael > Sent: Monday, July 28, 2003 6:12 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Suggestions for Academic-Type Users > > > Thanks for the reply, Nathan. > > 1. No real complicated rules. The user type determines what the users > see on the page. I use the user type to determine what main nav links > appear as well as certain types of content. Some pages may include > content that can be seen by multiple user types. One example of this is > the "My Courses" page. This page may show courses taught by faculty, > courses in which students are enrolled and courses in which a user may > be a teaching assistant. Some people may see different combinations of > courses. > > 2. On any page, I can tell which types a user may be. However, not > every page may show relevant content related to all user types. For > example, the courses page would not have anything to do with the > "employee" user type. Also, I have a "Links" page that pulls links from > a database table and compares it to the user types to determine what > links the current user is authorized to see. I guess that, other than > being related to a course, (by being a faculty member or student) one > user type is not really related to any other user type. > > 3. Course info (My Courses) is a sub-section of the site where > students/faculty can see course header information (course name, > dates/times/locations, instructor name, etc.), course syllabus, > course-related files, course communications between students, etc. This > information, and its main nav link, only appear if the user type is > either a student, faculty or teaching assistant or any combination of > these three types. My Courses doesn't contain enough data that it needs > to be cached. The queries return very small record sets so it would be > extremely difficult to see a difference between queries and cached data. > Most, but not all, of the information on My Courses is the same for > instructors and students. Students see and can do just about everything > the faculty can do except upload files/syllab or add teaching > assistants. Therefore, most of the methods can be used by both multiple > user types. > > Currently, my sesssion-based user object has many methods that return > information such as email address, group membership (from Windows), user > types, etc. > > I have a method in my user object, GetUserGroups() that returns a query > object that contains all of the user's user types. I can then use this > recordset to determine what the user is authorized to view. Most of the > time, I would use this method "attached" to my session user object. > > Currently, I only need to call objUser.GetUserGroups() to get a query. > However, sometimes, I may want to pass a user name through to find > another user's group membership such as GetUserGroups(Form.UserName). > Would you then suggest that I put this method only in an > application-scoped object or keep it in both? > > Man, there are so many variable factors to this... > > Anyway, thanks for your help. > > MAD > > -----Original Message----- > From: Nathan Dintenfass [mailto:[EMAIL PROTECTED] > Sent: Monday, July 28, 2003 4:39 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Suggestions for Academic-Type Users > > > Michael: > > I think to help you we'll need more information. For instance: > > 1) What are the implications of being one type of user over another? > That is, is it just a matter of deciding what to show on a given page > and which pages a user has access to, or are there more complicated > business rules associated with the user type? > > 2) Is a given user any or all of those user types at any one time? For > instance, am I a student in one part of the app and an employee in > another -- or am I both a student and an employee in various places? > > 3) What is "Course Info"? Also, is it something that needs to be cached > when a user logs in, or is it something you might just get from a > database when needed? > > You might consider separating things into stateful and stateless > components. The stateful "user" component might be cached in the > session and contain simple information like what user types the user is > and what permissions that user has. You might then have a series of > "service" components that live in the application scope that take an > instance of a "user" component as arguments for various methods. That > way, you can encapsulate the logic of knowing what to do for different > permutations of user type in your "services" and have the stateful > "user" store only enough info that your stateless service components can > do their thing. In other words, the "user" component stores the minimum > amount of information necessary to distinguish each user from another > while your common, stateless services can be reused for all users (and > probably involve some "heavy lifting" logic). > > One example might look like: > > thisUsersCourses = application.courseService.getCourses(session.user); > > (or, perhaps that's done when they log in and cached in the session -- > perhaps even in the user instance). > > > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Dawson, Michael > Sent: Monday, July 28, 2003 11:38 AM > To: [EMAIL PROTECTED] > Subject: [CFCDev] Suggestions for Academic-Type Users > > > I'd like some opinions or suggestions on how I should structure my CFCs > for the requirements listed below. > > I'm currently rebuilding our academic intranet site. This site contains > information for students, faculty and employees. > > Here is where it gets confusing (at least for me): A person may be a > faculty, student, employee or any combination of the above. Faculty and > students will see a list of the courses they teach or attend, > respectively. > > Examples: I'm only an employee. My direct manager is all three. My > co-worker is an employee and student. > > Each type of person has some similarities, but many differences. > Currently, I use a query object that contains records if you are one of > these types. I also only use a single "user" CFC that is stored in the > session scope. > > My first question is, should I, and how would I, develop a CFC structure > that would allow for these different types of people? > > My second question is, where is "course information" stored? Do I store > it in a "course-related" CFC or as part of the user CFC? In this > system, courses don't really exist without users. In other words, I > probably won't do anything with a course that doesn't directly tie back > to at least one user. > > Any suggestions? > > M!chael A. Dawson > Group Manager, Programming and Software Development > Office of Technology Services > University of Evansville > 1800 Lincoln Avenue > Evansville, IN 47722 > 812-479-2581 ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
