The attached patch adds three functions for quickly getting #options for form elements.
| Comment | File | Size | Author |
|---|---|---|---|
| form.inc.options.patch | 3.17 KB | Alex Reisner |
The attached patch adds three functions for quickly getting #options for form elements.
| Comment | File | Size | Author |
|---|---|---|---|
| form.inc.options.patch | 3.17 KB | Alex Reisner |
Comments
Comment #1
Steven commentedI'm not too hot about these. We don't like adding APIs unless they are actually used somewhere, and these seem to be APIs looking for a purpose rather than vice-versa.
function form_options_numeric_list($first, $last, $step = 1, $format = '%d', $blank = false) {Usually we do something like
drupal_map_assoc(range(1,10,1));. Drumm also recently made a nice patch (though not yet committed) for displaying units with form fields. So I'm not sure what else you could do with this that doesn't have a more compact solution.function form_options_query($query, $blank = false) {Doesn't support query arguments? Also, the blank option should have some visible label rather than an empty string.
function form_options_enum_field($table, $field, $blank = false, $caps = false, $spaces = true) {Database-specific code really belongs in the database abstraction layer, not in a form API. And then, it needs a functional equivalent for each. It's also very undrupallike to take UI labels directly from the database definition: they cannot be localized this way. And you should avoid unicode-unsafe functions like ucfirst().
Comment #2
Alex Reisner commentedOK, sounds like this is better suited for a module.
Comment #3
moshe weitzman commented