Michael Youngstrom wrote:
>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?
>
>
It actually does coerce to the empty String to null, for the Long bean
property. If I select "Empty" then null goes into my bean. My problem is
that the coercion is not consistent the other way. When it is deciding
which item should be selected, "Empty" is not selected from value being
null.
><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
>
>
Does "null" actually evaluate to null? Wouldn't one have to use "#{null}"?
Mark Collette
http://mark-icefaces-reflections.blogspot.com/