Last modified: 2012-04-16 09:16:04 UTC
Re bug #28152 and bug #28250: When HTMLForm is given two different fields with identical translations, the following error occurs: Global default '1' is invalid for field math Although Andrew says: > This is a deliberate design decision in HTMLForm, used to support grouped > options in select boxes. In theory it could have been done differently, I > suppose, but why would you want two options to be the same anyway? That's just > deliberately confusing. Either the translations should be fixed so that identical translations could be given, or HTMLForm should be fixed so it doesn't cause this problem.
To be clear, HTMLSelectField (and HTMLMultiSelectField etc) take options arrays of the form: array( 'message text' => 'value', 'other text' => other value, ); The reason the message texts are in the keys is so that grouped options using <optgroup> can be specified: array( 'message text' => 'value', 'other text' => other value, 'optgroup label' => array( 'label text' => 'a value', 'another label' => false, ), ); etc. There are two problems with attempting to flip keys and values: 1) It confuses the syntax for optgroups, as you cannot specify an array as a key, and there is also nowhere to put the message text 2) It means that the uniqueness must be in the array *value* rather than the key. While having identical keys is probably easier to get in practice, being able to specify multiple options as mapping to the same value is probably more *useful*.
Added some checks to Extension:Translate in r85131.
(In reply to comment #1) > <optgroup> can be specified: > > array( > 'message text' => 'value', > 'other text' => other value, > 'optgroup label' => array( > 'label text' => 'a value', > 'another label' => false, > ), > ); > there is also nowhere to put the message text There can also be arrays of arrays. Numerical keys. No problem afaic: $formFields = array( array( 'label' => 'message text', 'val' => 'valuehere', ), array( 'label' => 'other text', 'val' => 'other value', ), array( 'label' => 'other text', // same label 'val' => 'yet another value', ), array( 'label' => 'my optgroup', 'val' => array( 'One' => 'choise1', 'Two' => 'choise2', ), );
True, however now the syntax is getting rather dense and ugly, because the options array is already several layers deep in the descriptor array. What you actually have is something like: $formFields = array( 'MyButton' => array( 'type' => 'multiselect', 'label' => 'Foo option:', 'options' => array( array( 'label' => 'message text', 'val' => 'valuehere', ), array( 'label' => 'other text', 'val' => 'other value', ), array( 'label' => 'other text', // same label 'val' => 'yet another value', ), array( 'label' => 'my optgroup', 'val' => array( 'One' => 'choise1', 'Two' => 'choise2', ), ), ), ); As opposed to: $formFields = array( 'MyButton' => array( 'type' => 'multiselect', 'label' => 'Foo option:', 'options' => array( 'message text' => 'valuehere', 'other text' => 'other value', 'my optgroup' => array( 'One' => 'choise1', 'Two' => 'choise2', ), ), ), ); Which is significantly more compact, and arguably more readable too. And building those associative arrays from generators like Language::getLanguageNames is not going to be particularly pretty, probably with lots of foreach loops. In a strongly typed language we'd have no difficulty making some sort of structure for this. With what we have, I'm not convinced that an associative array is a good way to solve this.
I think it's a matter of taste. I see no problem with the longer syntax, but anyway, I can see both working. However in general using freeform text as array keys doesn't sound like a good idea, and there's ofcourse this bug 28313 for which I haven't seen another solution.
