I should have proofread that email. :)
Again perhaps I am misunderstanding the problem but I think the spec
should say that that Menu Component should preserve the values of it's
SelectItems. For example:
<h:selectOneMenu value="#{someBacking.value}">
<f:selectItem itemValue="10" itemLabel="10"/>
<f:selectItem itemValue="" itemLabel="Empty"/>
</h:selectOneMenu>
If label "10" is selected it should put that value into
#{someBacking.value} doing the appropriate EL coercion.
If label "Empty" is selected then it should attempt to put an empty
string into #{someBacking.value} following EL coercion rules I'm not
too good at the EL coercion rules but if #{someBacking.value} were a
Long it may actually put '0', null or perhaps throw an exception?
<h:selectOneMenu value="#{someBacking.value}">
<f:selectItem itemValue="10" itemLabel="10"/>
<f:selectItem itemLabel="Null"/>
</h:selectOneMenu>
If label "Null" is selected then it would put 'null' into
#{someBacking.value} following appropriate EL coercion rules. So, if
the type of the value binding is a primitive 'long' then it believe it
would insert a '0'???
<h:selectOneMenu value="#{someBacking.value}">
<f:selectItem itemValue="10" itemLabel="10"/>
<f:selectItem itemLabel="Null"/>
<f:selectItem itemValue="" itemLabel="Empty"/>
</h:selectOneMenu>
In this situation there would obviously be a problem. I think it
would be handled in the same way that duplicate itemValue are handled
which is probably first item wins?
The point is that I think itemValue should always be preserved. Or
maybe I'm missing the problem all together?
Mike
On Feb 15, 2008 10:51 AM, Ed Burns <ed.burns_at_sun.com> wrote:
> >>>>> On Thu, 14 Feb 2008 21:31:14 -0700, Michael Youngstrom <youngm_at_gmail.com> said:
>
> MY> is why null values work for me? Either way whether since the spec
> MY> doesn't explicitly say what to do with null selectItem values I think
> MY> the correct behavior should be to preserve and correctly select null
> MY> values. Especially since I'm pretty sure that in some situations that
> MY> is the current behavior so if nothing else I think we should be
> MY> consistent here.
>
> Do you think the spec should say what to do in this case?
>
> Ed
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>