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]On Behalf Of Dawson, Michael
Sent: Monday, July 28, 2003 11:38 AM
To: [EMAIL PROTECTED]
Subject: [CFCDev] Suggestions for Academic-Type UsersI'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. DawsonGroup Manager, Programming and Software DevelopmentOffice of Technology ServicesUniversity of Evansville1800 Lincoln AvenueEvansville, IN 47722812-479-2581
