Re: Re: DataObject and enums

Alan, Thanks for your ideas. I very much look forward to MDB_DataObject for many reasons, the largest is the my belief that all info for a field should be in one place, allowing consumers of this info to override as needed. I have a running experiment I'll post on a new thread. -mitch On Wed, 2003-06-25 at 19:00, Alan Knowles wrote: > 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? -- Mitchell Perilstein mitch at enetis dot net www.enetis.net/~mitch