Posted by Alex Reisner on November 28, 2005 at 8:25pm
3 followers
Jump to:
| Project: | Drupal core |
| Version: | x.y.z |
| Component: | base system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
The attached patch adds three functions for quickly getting #options for form elements.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| form.inc.options.patch | 3.17 KB | Ignored: Check issue status. | None | None |
Comments
#1
I'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().
#2
OK, sounds like this is better suited for a module.
#3