| Drop Down Helper for CI - has saved me lots! |
Easy to use CI Dropdown Helper.
https://github.com/IgnitedCoder/ci_dropdownhelper Enjoy..Share...change as you see fit. Brendan
This helper is redundant, as similar dropdown helper is part of CI core. See http://www.codeigniter.com/userguide3/he...m_dropdown
I know most of this can come across as overly-critical or confrontational. I'm hoping that I can just say up front that I don't intend it to be that way, but I want to fully explain the process I would go through if I were building a similar helper.
You should be checking for empty/invalid values rather than just slapping parameters into the select element. Also, the choice of parameters and their order for the build_dropdown() function in your helper is questionable. To be fair, this is true of CI's form_dropdown() as well, but they can blame a combination of backwards compatibility and consistency within the helper. You created a separate function to build out your option elements, which may have some benefits in terms of being able to replace the function, but adds a function call for every option in the dropdown (and an additional global function definition). Additionally, you don't support optgroup elements (which may not be commonly-used, but it's not as if you have to support dozens of potential elements here, as option and optgroup elements are the only valid content for a select element). You have six parameters, 4 of which ($classes, $name, $dropdown, and $selected_value) are required. Optional parameters should go at the end of the argument list, but your first and last parameters are optional. How is $id really optional if you have to supply the next 4 parameters? As an example, think of what is necessary to build a dropdown: - options - ... Actually, that's it, just the options (and really, according to the HTML spec, they're not required, either). So, unless you have a set of functions which need some consistency in arguments or you're specifically building dropdowns for use in forms, the options are really the only required part of the dropdown. The next two I could see going either way, and that would be the name attribute and the selected value. If this were a form helper, I would even say the name attribute should go before the list of options, because a dropdown in a form needs a name to be submitted as part of the form, but you only need a selected value for existing data (or when providing a default value). Since a dropdown can allow multiple selections, the selected value parameter should permit either a string or an array, but, if it's an array, we should make sure the multiple attribute is included if multiple items are passed. The id, class, and onchange are all attributes, so we could probably use a function like the form helper's _parse_form_attributes() to handle all of those as one parameter, and anything else the user might need (for example: autofocus, disabled, form, multiple, required, and size are the attributes, other than name, specifically listed for select elements in the HTML5 spec, which would be in addition to the 12 global attributes, event-handler attributes, and custom data attributes). Since the name is also an attribute, we could handle it in the same parameter. If we were building this function specifically for forms, we might want to make sure the name attribute is set, but that's not a big deal. Given all of this, and the fact that, in the end, we can safely build an empty select element without any of the arguments, I guess our parameter order really only matters in terms of how we see it being used. I would expect that dropdowns outside of forms or without any attributes are rare, and a dropdown without options is also rare, so these would be the most important. The selected value(s) parameter is the most likely to be excluded, so it would be last. To choose the order of the first two parameters, I could flip a coin, but I think about it more the way I would go about building a select element by hand: build the select element itself (with the attributes), then build the option elements. Further, making the options the second parameter maintains some association with the selected value(s) parameter by keeping them in close proximity. This would give us the following: PHP Code: function buildDropdown($attributes = array(), $options = array(), $selected = array()) If you wanted to get really crazy, you could add support for a more complex $options array to include attributes on the option elements, and while I've hacked together something in the past to do this via an extra parameter, it's probably better to support it via a more complex $options array. The more I think about ways to add new features to a function that builds dropdowns, the more it reinforces my belief that no more than 3 parameters are needed for this function. |
| Welcome Guest, Not a member yet? Register Sign In |
