this: new Boolean[] { null, True, False }.
is not the same as null is a valid value!
Because you really specify the null as a thing you can choose.
isNullValid is more: new Boolean[] { True, False }.
and then if isNullValid() == true then we (the framework) generate the -1
value..
So if you just specify it your self in the choices then you completely do it
yourself.
johan
On 10/7/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
Say you have list of options - new Boolean[] { null, True, False }.
so Null is a valid value. Why don't we allow choice renderer to assign
id value for null in this case?
I think when isNullValid() is true, we should allow choice renderer to
generate id even for null value (because it's valid). If null is _not_
valid, then we should either return "" or -1.
Does this sound sane?
-Matej
Johan Compagner wrote:
> i think we can drop that NO_SELECTION_VALUE
> and just return "" for it in AbstractSingleSelectChoice
> so that it is consistent with what ChoiceRenderer does
> Calling choicerender directly doesn't seem to be a good choice
> because that is just a default implementation..
>
> johan
>
> On 10/6/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> There is a inconsistency of how null is handled in
>> ChoiceRenderer#getIdValue and AbstractSingleSelectChoice#getModelValue.
>>
>> ChoiceRenderer renders either "" as id, or index under which the null
>> value is in choices list.
>>
>> AbstractSingleSelectChoice#getModelValue returns always -1 for null.
>>
>> The outcome is that if RadioChoice has item with null value and the
>> model object is also null, the item is not pre-selected.
>>
>> (because getValue() is compared to
>> getChoiceRenderer().getIdValue(choice, 0))
>>
>> It is a bug, but I'm not sure what would be the best way to fix it.
>>
>> Perhaps when AbstractSingleSelectChoice#isNullValid() is true the
>> getModelValue should call choiceRenderer.getIdValue(object, index) even
>> for null objects?
>>
>> WDYT?
>>
>> -Matej
>>
>
