Support for some sort of ENUM type


We have a lot of instances where we store what is essentially an ENUM in the DB as a plain varchar and use a “format” restriction on the preside object property to limit the possible choices. We then invariablly manually make the form control for these fields a select list with pre-defined values and labels to match the possible choices.

I was thinking that we should formalize this with a settings.ENUM structure in Config.cfc:

settings.ENUM = {};
settings.ENUM.pageAccessRestriction = [ "inherit", "full", "partial", "none" ];
settings.ENUM.emailSendingMechanic = [ "custom", "manual", "scheduled" ];

There would then be a corresponding .properties file for each entry in the ENUM type:

// /i18n/ENUM/



In our preside object’s we could do:

property name="access_restriction" type="string" dbtype="varchar" enum="pageAccessRestriction";

And finally, we would have two form controls, ENUMSelect and ENUMRadios, that used the enum type to automatically populate selection UIs for you (radio list could include enum item descriptions). If you used enum in your preside object property, one of these would be chosen as the default form control for that property.


I’ve created a JIRA for this here: and work has begun (the above has been implemented and now needs documentation).


Makes sense. I’m not sure the existing method of having the restriction as a validation is ideal, and I assume we currently have to maintain the restrictions and labels etc in separate locations? The enum proposal gathers all this into one place while also allowing any number of auto-populated form controls to be derived from the Enum.


Exactly that. Current approach is haphazard.


I just remembered also what prompted this: auto expressions for these fields in the rules engine / filters. We can configure an enum field type that will select from the enum items, rather than just a plain text match, so that auto generated filters/expressions for these fields are usable :slight_smile: