DataObject and enums

How does everyone handle the SQL "enum" type? Or more generally, multivalue data fields usually presented as HTML <select> widgets. If it's a small project, I find it nice to have a separate table for the set of elements in that selection type, then scan the whole table to generate the <option> elements inside the <select>. This way, the elements are all in one place and always in sync with the form template. But if you have a lot of select boxes, you have a lot of tables to bring in every page view of that form. Caching won't help because it's a form. Ideally, these things are mostly invariant and storing them as class methods makes sense. See HTML_Select_Common_USState and _Country. What would be really slick is to have DataObject's Generator make methods called fooToString, fooGetAll, and fooStringToInt for each column 'foo' in the SQL of type ENUM. The hard part of this corny scheme is that DB::tableInfo will tell Generator that it's an enum field, but not what the values are. So all of DB's db drivers will need to learn how to ask the db what all enum values are possible. A less automated scheme would be to have separate tables, like in my second paragraph, but have Generator know how to scan those in and produce the static methods. How does everyone else do this? -- Mitchell Perilstein mitch at enetis dot net www.enetis.net/~mitch