My suggestion was based on my own user problems. Been thinking about a similar problem for a while, but haven't come up with a solution that I like yet.
I was thinking that there would be a method called getFullUser(id) that
would do database access to create a full user - i.e. with the structure of
user types fully populated. Then you could call isUserType("student") to
test if this user is a student, etc. You don't need to know if the user is a
student beforehand (except when first building the user object). However,
this probably creates a bloated user object which may be an issue since you
want to store it in a session scope.
As for the inheritance, the main part was the all the user types came from a
single super class so that the structure of userTypes were all of the same
(super) class. This allows you to avoid having methods named isStudent() or
isFaculty(). The reason for avoiding this is so that you can change the user
types without changing the core code. As for the rest of the inheritance -
that was just a bad guess.
Like I said, this may not suit your needs. It's probably closer to what I
want. I'm looking forward to see suggestions from other people.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Dawson, Michael
Sent: Wednesday, 30 July 2003 5:19
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] Suggestions for Academic-Type Users
Rod, thanks for the reply. I do have another question about the
inheritance of the classes.
First, we have no real hierarchy of user types. A student may be an
employee, a student may be a faculty, an employee may be only an
employee, etc.
I don't see how a single pattern could accomplish this. Here is a list
of all the permutations that are currently possible:
Employee-only
Faculty-only
Student-only
Employee - Faculty
Employee - Student
Employee - Faculty - Student
Faculty - Student
It would seem that I would have to "know" what the user's types are
before actually creating the instance. Then, I would be able to choose
the correct class type such as "CreateObject("component", "EmpFacStu")
or "FacStu", etc.
Am I missing something?
Thanks
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Rod Buchan
Sent: Tuesday, July 29, 2003 4:34 AM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] Suggestions for Academic-Type Users
Here's a suggestion, I haven't tailored it to your needs exactly (sorry
about that). It's written in pseudo-code so it's easy to read.
Feel free to shoot this down, I'm looking for flaws.
class User
----------
string name
string address
string username
string password
struct userTypes //This contains a structure of different user types for
this user
//Method to check if user is of a particular type
boolean isUserType(_typeName){
if (userTypes.keyExists(_typeName))
return true
else
return false;
}
//Method that returns a reference to the userType
UserType getUserType(_typeName){
return userTypes._typeName
}
//Add user type to structure
boolean addUserType(_type){
typeName = _type.typeName
userTypes.typeName = _type
}
class UserType
--------------
string typeName //super class
class Student extends UserType
------------------------------
//student properties and methods
class Staff extends UserType
------------------------------
//common properties and methods for Faculty and Teaching Assistants
class Faculty extends Staff
class TeachingAssistant extends Staff
class Employee extends UserType
etc
Obviously this all needs to be fleshed out - you may prefer a to use a
list or array to hold the userTypes. The main point being that you have
a single user with one or more extra types. Since the extra types are
all of type "UserType", you can keep adding more and more types without
breaking/modifying the user class. Plus you can modify any of the
UserType subclasses as much as you like. Seems like pretty decent code
separation, plus it's a good basis for future enhancements.
Not sure if it meets your needs.
Cheers,
Rod
----------------------------------------------------------
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).
<<attachment: winmail.dat>>
