I totally agree with your comment about isThis OR isThat AND isMy... That's why my current method is to pass a list of authorization types (which may include types such as "student", "faculty" etc. I can either get that list from a database or hard-code it.
I'll have to dig in to the numbered hierarchy to see if it will fit with our current system. It's a home-built system based off of a mainframe and AS400 that can be a bit quirky. Therefore, I tend to stick only to read-only data. BTW, if you don't mind me asking, what administrative/academic software do you use at your school? Thanks -----Original Message----- From: Adam Wayne Lehman [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 9:29 AM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Suggestions for Academic-Type Users Mike, As there are a million ways to skin a cat, there are a million and one ways to manage user types: In my system each user is assigned a defaultUserLevel. This is a number with 1 being the all powerful systems developer and 500 being a default 'powerless' student. Then tied to each enrollment record there is an enrollmentUserLevel. The enrollmentUserLevel of course overrides the defaultUserLevel. This allows for a student in one class to be a TA or Faculty of another. The system previously used a bunch of boolean fields to determine isFaculty or isAdmin or isStaff. But quite frankly they were pointless. If this is all surrounding what this one page looks like, then I wouldn't recommend a bunch of 'is' variables. Your biz-logic is going to turn into an encyclopedia of 'if isAdmin but not isFaculty all the while isStaff but could be isStudent'. With each 'is' variable you are going to have to write more and more business logic that you will no doubt see a lot of code redundancy. Think of the amount of code you'll have to change when you want to add a new user type like 'isGuest'. If you stick with a numbered hierarchy then you'll save yourself a lot of headaches. If your IDs want their myCourses page to have their classes on it, then you can enroll them in those courses with a lower defaultUserLevel. A level that is lower than the default student level (so they aren't displayed on rosters and what not). Is there some unwritten rule in higher education that all courseware systems have to have at least one application name myCourses? That's what my boss named our courseware administration. Adam Wayne Lehman Web Systems Developer Johns Hopkins Bloomberg School of Public Health Distance Education Division -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dawson, Michael Sent: Monday, July 28, 2003 9: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). ---------------------------------------------------------- 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). ---------------------------------------------------------- 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).
