Does anyone have a good solution for enumerated types in EOF Applications?
Example:
In my bug database project, I have several user types:
"SW Engineer"
"QA Engineer"
"SW Manager"
"QA Manager"
"Internal Test Site"
"External Test Site"
"Administrator"
These are stored in the database as a number, not as the string.
So I've written a bunch of code to map back and forth between the
strings and the numbers, so that I can put a WOPopup in a form, and
let the user select what type of user they are, etc.
This requires 3 extra procedures for each attribute.
+ (NSArray *) typeLabels; //returns an array of strings.
- (NSString *) typeLabel; // returns a string corresponding to the
// value of "type" a numeric attribute of User
- (void) setTypeLabel; // sets "type" according to the value of string
// by looking it up in typeLabels.
The thing is, its kind of tedious to do this all the time, and my
WebScript code can't deal with the enumeration anyways because
WebScript doesn't support enum{} declarations. (My rule on OO design
is that if I can make my code smaller, while retaining the same
function, the design is improving.)
What I'd really like is for EOModeler to support a type that can be
either a number, or a string from a short list.
So I'm looking for alternatives to my current solution, so I thought
I'd throw the idea to the list to see what other people have done.
These are the alternatives I've thought of myself.
Alternative #1: (Use the database)
I could store all the enumerations in a table, that maps indexes
to labels. Each set of labels would have to be a seperate label. In
other words, I could have a table called "user_types" that holds the
above strings, and a primary key for each label.
Advantages:
The enumerated type is configurable.
Disadvantages:
It seems overkill. While the enumerated types are configurable,
that's either another WO screen of detail to administrate, or some
SQL hacking. Also, there's no good way to map back and forth between
the type information stored in the database and the code.
In practice, your WOApplication object either needs to fetch the
list of user types on startup, or you need to have a WODisplaygroup
for each popup. If you fetch the list of user types on startup, you
need to update the list if it gets added/subtracted from...
So this method is appropriate for some things, but not others. In
my case, I could also store in the "user-type" table what steps are
appropriate to take for that type by default, and have a completely
customizable user set. I thought that was overkill, which was why I
didn't do that!
Alternative #2: (Custom data type)
EOF does support implementing your own datatype as the destination
of a table column. I suppose I could implement a TFEnumeration that I
could then use as the destination. That object could then be queried
for its value either as a string or as a number.
Advantages:
Reusable?
Disadvantages:
Having never done this, I'm not sure how well custom types work
with EOModeler and WOBuilder. I'm also not sure exactly what
protocols I have to implement, and I didn't find much in the manual.
Also, there's still the configuration problem for the type. How
do you establish the number->string mapping? Do you have to make a
sub-class for each different enumeration?
What have y'all done in similar situations? Is there something I
haven't thought of?
Pierce
----------------------------------------------------------------
Pierce T. Wetter III, Director, Twin Forces, Inc.
e-mail: [EMAIL PROTECTED] Phone:520-779-4227
<http://www.twinforces.com/>
U.S. Mail: 1300 South Milton Rd, Suite 206, Flagstaff, AZ 86001
