Re: DataObject and enums

how do i do it :) - mostly the lazy way and just create forms with (what would be) the enum values as select boxes.. / or hidden.. - and avoid using enums.. I remember using hooks in Generator to detect enums and do something special when writing FlexyForms (depreciated - dont use it). But that only used hooks to call functions in DataObjects, rather than actually exporting the enums. Since it doesnt change to often, It may be worth considering for MDB_DataObject, which should have a 'richer' schema description than database.ini. (although AFAIK the MDB schema doesnt support enums yet) Regards Alan Mitchell Perilstein wrote:

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?