Very interesting. I originally started with methods such as those you suggest. I may go back to using those for convenience like you say.
I will add that my user object also pulls Active Directory group
membership and stores it in the same query object as the user types.
(You will see this in the attached code.)
The reason for having the AuthorizeUser() method is I can pass in a list
of groups/roles/types/whatever that may be too open-ended for which to
create individual methods.
Currently, I can use objUser.AuthorizeUser('user type student,user type
faculty, etc.') which is an open-ended equivalent of
"objUser.IsStudent() OR objUser.IsFaculty". However, I like the idea of
having both solutions.
So, from reading your replies, you don't really mention any need for
inheritance and I don't really see how it would be possible. For
example, I could have a base type of "User" which is extended by
"Student". Additionally, I could have "Faculty" which also extends
"User". However, if the person is both a faculty and student, it would
be ambiguous to pick either student or faculty which would extend the
other which, in turn, would extend the "User" type.
There just doesn't seem to be a very good hierarchical flow to this,
therefore, I think I'll just let the object "tell" me what types of user
this person really is.
Your suggestions for the Course Info are very good. I'll probably
implement that fashion of coding to clean up what I already have. I
like how you use the suffix "Service" to clarify the reason for the CFC.
As you can tell from my code, I have CFINCLUDEd several UDFs in my code.
By using application.UserService.method(), I won't have to worry about
redefining UDFs that may appear somewhere else in the request.
You are right about the factory. My site doesn't really have the need
to generate user instances except only the instance required for each
user that will be stored in their own session scope.
Thanks again. I really do appreciate your assistance and suggestions.
Mike Dawson
-----Original Message-----
From: Nathan Dintenfass [mailto:[EMAIL PROTECTED]
Sent: Monday, July 28, 2003 11:44 PM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] Suggestions for Academic-Type Users
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).
User.cfc
Description: User.cfc
