Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Selected Options in Select Form Elements?
  • Let's say I have a form that has a select dropdown box. In this box I have a list of numbers. It's possible that you might have chosen a number on a previous form. So in that case, I would like to mark a pre-selected option as 'selected'. The documentation isn't terribly explicit about the correct method of doing this, but the following is what I tried:
    $form = Form::select('numbers', 'none', 
     array( // options
      '1' => 'One',
      '2' => 'Two',
      '3' => 'Three',
      '4' => 'Four',
     ),
     array( // attributes
      'selected' => '2'
     )
    );
    

    The output of this code is:
    <select name="numbers" id="form_numbers">
     <option value="1">One</option>
     <option value="2">Two</option>
     <option value="3">Three</option>
     <option value="4">Four</option>
    </select>
    

    I would have expected the number 2 to be selected. Something like:
    <option value="2" selected="selected">Two</option>
    

    I quickly traced through the core's code for the form class, and it appears to take selected attributes into account, but for some reason it's either ignoring my directive, or I'm doing it wrong. Any ideas or examples of how it's supposed to be accomplished?? Thanks!
  • Read the docs again. The second param is the "selected" value, when given this overwrites whatever is passed in the last param. Thus in your case you're selecting the non-existant value "none".
  • Jelmer. Thank you for the reply. That does indeed work. I appreciate your willingness to help and the effort you contribute. I do however want to follow up on your statement that I "Read the docs again." -- essentially RTFM. I must have read and re-read the docs 20 times. I did so again today and I still feel it's very poorly worded. First, the summary contains several spelling and grammar mistakes (underlined) making it difficult to parse, let alone understand:
    Creates an html select element. It can be set using the fieldname, it's selected value(s), it's options and tag attributes or all in one attribute for the first arguement.

    Secondly, from the above, I can only assume "fieldname" is the same as "$field"? It's odd to me that you can use the first parameter to either set the field's name attribute, or pass in an array with a whole host of other attributes. I'm curious why this decision was made--seems an odd use case given the existence of the aptly named $attributes. Next, it's unclear to me what the 3rd sentence means. I appreciate brevity as much as the next person, but I think I'd prefer a little more meat on this bone (so to speak). I would offer to rewrite it, but I'm really not sure what the last part is trying to say. Lastly, and most importantly, the explanation for pertinent second parameter is thus:
    Field value or array of values when multiselect, will be ignored when the first param is an array.

    "Field value" does not make me think "selected option", it makes me think it's an alternative way of passing in options or values for options. Compounding the confusion is that the parameter's name is $value. Why not $selected or something clearer? Is this an artifact from refactoring? Did I miss something in the HTML standard where "selected" and "value" are synonymous? I understand that there are a lot of things to document and it's not an easy job. Simultaneously developing code and then attempting to forget what you know just so you can describe it to an unfamiliar audience is really challenging. So can we stop pretending the docs are gospel and concede that some descriptions are prohibitively difficult to understand? I'm not sure who to address this request to, but it would be incredibly helpful to have commenting attached to the docs. Or convert the docs to a wiki. Is the only method of contributing to the documentation to fork and hope the changes get pulled back in? Sorry, I don't mean to sound overly critical here. I am really impressed with Fuel and the community here. It's been a lot of fun getting acquainted with it. I would just hate to see the adoption rate and popularity take a hit because of gaps in the documentation. If the solution right now is to use github to edit the docs, I'm more than happy to make a contribution there. Thanks again. EDIT: Formatting
  • That's the reason the docs are in a repository of their own: you can make issues or (better!) pull-requests to correct anything you feel is wrong. You have a couple of good points there about the wording, but know that we only fix what's in the issue tracker (this isn't a paying job, so we only fix what we know "officially" or encounter ourselves). So if you feel something is wrong, either report it in the issue tracker or fix it yourself and pull-request.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion