Last modified: 2009-08-13 15:26:09 UTC
Xml::listDropDown does not recognize the $selected parameter when it's passed in the argument listing. The selected option defaults to the $other parameter, which if not passed is empty.
Created attachment 6368 [details] corrects Xml::listDropDown method to accept $selected parameter if passed This patch was prepared on MediaWiki version 1.15.1.
Testing with current dev trunk, seems to accept the selected parameter just fine for me... > return Xml::listDropDown('name', "a\nb\nc", 'theother', 'b'); <select id="name" name="name"> <option value="other">theother</option><option value="a">a</option><option value="b" selected="selected">b</option><option value="c">c</option> </select> ^ option 'b' is selected as expected > return Xml::listDropDown('name', "a\nb\nc", 'theother', 'other'); <select id="name" name="name"> <option value="other" selected="selected">theother</option><option value="a">a</option><option value="b">b</option><option value="c">c</option> </select> ^ option 'other' is selected as expected A couple notes: First, in current code the $other parameter doesn't appear to be optional currently; an "other" option will always be added in the current code. The patch makes it optional, which may or may not be what's desired in usage. Second, exact comparisons are used (===), which means if you're using numbers for your values you might be getting false negatives -- 1 won't match "1" for instance. Using coercible comparisons (==) will let those through but could also create false positive matches in some cases, for instance if you're trying to select between "1" and "01" or something. Not sure we want to introduce a change here. Personally I think I'd rather just junk this function and replace it with an interface that's not awful. ;) Building the option set from a formatted string is a really nasty interface.
Hmm...I tried passing and not passing the $other parameter and did not get the desired selection.... I also tried passing the options list with and without asterisks (in my case I was building an options group so had to designate that, which was done with * vs ** for the options), with each option separated by \n as well... On the exact comparisons...I was not passing number for the values but was instead passing text, and did not get a valid comparison until I changed it to "==" from "===". I'm not a big fan of this method either...it doesn't feel intuitive to me. Plus it did not appear that it was in use anywhere in the Mediawiki core code. On scrapping this for a better interface....is that in the works for a future release?
I think we can close this bug....I was unable to duplicate the problem. Seemed to be operator error due to lack of sleep. Sorry!
