Drew,
I can see why you want to do this, but you should at least consider
making this a many-to-many relationship as well.
While using this powers-of-two system will allow you to easily embed
many Types with a single to-one relationship, you will need code that
can recognize any possible combination. With only three types it's
pretty straight forward, but as the number of Types increase the
number of possible combinations increases exponentially and writing
code to parse the integer value into Types will get ugly.
I suggest using the same design pattern as option 2. Create an
intermediate class of EmployeeType that will have one instance for
each Type the Employee can be. You will still be able to select only
the Employees that have a type of Consultant and the code will be
much more transparent while debugging and for the next coder to come
along (or when you have to make revisions to it in 4 years).
Dave
On Dec 4, 2005, at 6:57 PM, Drew Thoeni wrote:
I'm giving that a shot and will see how well it works. One oddity
about this is that an employee can be more than one of these things
(they can be a project owner on one project, and a project manager
on another. So I'm using a type code as part of the qualifier that
allows the employee attribute of "type" to have a coded integer
value where 1=owner, 2=consultant, 4=manager. This allows for a
type of 3 = owner or consultant.
What I'm trying to do is build a pop-up list showing only those
employees that could possibly be a consultant. The qualifier for
the consultant subclass is ((type=2) or (type=3)).
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
