When using a LinkedHashMap to populate the <option> tags with the "options" parameter I expected the value in the key->value pair to appear between the <option> tags. Basically I would expect to see the longer, more descriptive, string appear in the pull down list. the <option value="key"> is where I would expect the HashMap's key to appear since this is the shorter, more concise string I will want to store and/or use in calculations. I know it is a bit of a misnomer, since the option tag calls it a "value" but what I would really like there is the item you are calling the "label" So if I was to pass in the following LinkedHashMap: LinkedHashMap map = new LinkedHashMap(3); map.put("1", "one"); map.put("2", "two"); map.put("3", "three"); <input:select name="number" options="<%= map %> /> I would expect it to generate the following HTML: <select> <option value="1">one</option> <option value="2">two</option> <option value="3">three</option> </select> If this is just a matter of opinion, it would be great to have a switch that allowed me to determine whether the value or the key gets displayed in the list with the other stored as the option value. The code that handles this seems to be in the Select.java file, the outputOption method around line 205.
FWIW, I agree with your assessment. But the tag works exactly as advertised, and reversing the key-value semantics will be an incompatible change. I'd hesitate to call this a blocker.
Yes I agree as well. It is counter-intuitive but I'm sure there was good reason for it initially, and I guess you can see an argument both ways... as you say: the option tag does have a value, which suggest that a select tag is a key to value mapping. It's just not perhaps how we see keys from a Map & Java perspective. As Rahul said it would be an incompatible change. I find the optionLabels and optionValues a more flexible option: full control over the order of labels and no misunderstandings. The only way I can see that this change could be made would be if an additional attribute was added to the tag, eg. reverseOptions="true" but hopefully with a better name. Something along those lines would be a simple solution I believe. Thoughts? Alternative is to mark this as WONTFIX or INVALID I guess.
(In reply to comment #2) <snip/> > As Rahul said it would be an incompatible change. I find the optionLabels and > optionValues a more flexible option: full control over the order of labels and > no misunderstandings. <snap/> Not sure what you mean here, separate lists for labels and values? > The only way I can see that this change could be made would be if an > additional attribute was added to the tag, eg. reverseOptions="true" but > hopefully with a better name. Something along those lines would be a simple > solution I believe. Thoughts? <snip/> Hmm, the semantics of "reverse" will have to be documented and anyone who finds the current rendering counter-intuitive will also find the above attribute counter-intuitive ;-) > Alternative is to mark this as WONTFIX or INVALID I guess. <snap/> I'd WONTFIX this, reasoning in terms of backward compatibility.
Yes, there are optionValues and optionLabels lists. These are separate lists for values and labels. The attribute with a Map has limited control over the order in which you want things to appear - you either have no specific order or sorted etc. Whereas you have complete control with the pair of lists. Also there is the nested <input:option ... /> tag :) I agree - let's WONTFIX this. Jeremy, please feel free to discuss this further.
I understand the problem of backward compatibility, but a flag would still be a good modification. Is anybody using the options parameter and giving it a map? To me, this could be the most useful tag in the entire library, in fact, it would be the only one we are using. The rest are nearly identical to a plain old input tag. By giving the options attribute a LinkedHashMap you could quickly generate the list you want to see and have it return the key to be used to manipulate the data. I posted this because we honestly found that this tag was useless without it. For our purposes it's easier to just build the select option list on the fly with Java code in the JSP. But if others are getting value (no pun intended) from using this tag then that's great. Thanks for the discussion.
Thanks Jeremy. I have reopened the bug. I'm sure there are people getting value out of it the way it currently is - probably people who remembered about the LinkedHashMap, unlike me :) - but it's obvious that you'd get value out of it the other way around. In which case there are bound to be others who would too. I propose that we do one of two solutions: 1) Add a new attribute for options that are accepted in the value->label order rather than the current label->value order. I'm struggling to name this attribute, perhaps optionsValueLabel and in which case we could add optionsLabelValue as well and deprecate options. 2) Add a boolean attribute to choose between the two orderings. The original ordering would be the default. I'm also struggling with naming this one, perhaps optionsValueLabel="true" ? I'm leaning toward option 1 as it is less to type when you're using the tags. The attribute names still feel a little verbose though. Please add your feedback.
I like option one too, it feels more OO to me and easy enough to understand if properly documented. It is a tough one to name but I would be willing to write the documentation. So what's the procedue then? How do we implement this change?
This has been resolved in commits today (revision 531132). An "optionsValueLabel" attribute has been added. The existing "options" attribute has been left as is.