On Wed, Dec 21, 2011 at 1:38 PM, Jens <jens.nehlme...@gmail.com> wrote: > I am one of these guys who loves to have a null value in a ListBox to be > able to "deselect" things in a ListBox. > > So my server just gives me "a,b,c" and I call setAcceptableValues() with > this list without any call to setValue() before (new view, activity loads > list of acceptable values and just sets them). ValueListBox now appends null > at the end and in my renderer I check for null and render it like "please > choose" or something. Wouldn't this patch break the app behavior for > everyone that has implemented it like this? Because with this patch > ValueListBox would select "a" and I am not able to deselect anything > anymore. I don't think its uncommon.
First, if you allow for a 'null' value, then it should be part of the collection you pass to setAcceptableValues. Here, if you put the 'null' at the end of the list, it would break your code anyway, *except* that: you're assuming the value is still 'null' at the time you call setAcceptableValues (if it weren't the case, that'd break your app, as you wouldn't have a 'null' entry), so you'd probably have no problem calling setValue(null) before (or after) calling setAcceptableValues. So, anyway, you should fix your code. > Anyways maybe my app isn't affected anymore to this patch because I decided > that its nicer to have the "null" selection at the beginning of my entries > in ValueListBox. So nowadays I add "null" at the beginning of the list of > acceptable values. So my List now contains null anyways. Yep, that wouldn't affect you in this case. > Until now I don't even recognized that setValue() actually adds and select a > value to the ValueListBox if its not in acceptable values. I never really > read the JavaDoc on setValue because if I see two methods: > setAcceptableValues() and setValue() I assume that setValue() can only take > values that are defined by setAcceptableValues(), otherwise it will do > nothing or throw an exception. So it seems a bit strange to merge both. I > guess the idea of merging acceptable values with the selected value is the > root issue here. Possibly, but if you're only supposed to setValue something that has been passed to setAcceptableValues, you should check it upfront anyway, rather than relying on some specific behavior of setValue (do nothing or throw). The behavior of ValuePicker is more discussable for instance, as it would "logically" select an "unknown" value without adding any visible clue; from the user point of view, selection would be empty. ValuePicker would be great for use cases where a value had been selected but should no longer been presented to the user; if the user doesn't change anything in the field, the old value is preserved. I think the same behavior would be possible for ValueListBox, but it would be a major change (more than slightly changing the behavior of setAcceptableValues in the way Stephen proposes here). That being said, I still believe ValueListBox is *not* broken; just that its behavior is a bit counter-intuitive. -- Thomas Broyer /tɔ.ma.bʁwa.je/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
