If you're using facelets, you can write static functions....
toInteger("1"), etc.
I don't think the spec leaves any room for coercing the types.
The other solution (far easier) is to create your own selectItem (or
enhance t:selectItem) to coerce the values automatically like the
1.1.3 version did.
On 3/14/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
That is very unfortunate, as it makes it impossible for <f:selectItem>
to ever work with non-String values. The fix that "Daniel Campagnoli
[06/Nov/06 01:24 AM]" proposed seems much better. Even this fails:
<t:selectOneRadio value="#{bean.value}">
<f:selectItem itemValue="#{1}" />
<f:selectItem itemValue="#{2}" />
</t:selectOneRadio>
So in this case it is not possible to create a select item from the
view that uses "int" values in the backing bean. Since <f:selectItem>
never converts the value, this change to 1.1.5 really makes that
component useless, which is much more severe of a problem than the
original 1328 bug that was reported.
Any way around this one without making all select items always come
from backing bean properties or always using string data types?
On 3/14/07, Simon Kitching <[EMAIL PROTECTED]> wrote:
> See:
>
>
http://www.nabble.com/ERROR%3A-Value-is-not-a-valid-option-tf3270984.html#a9163090
>
> and:
> http://issues.apache.org/jira/browse/MYFACES-1328
>
>
> Andrew Robinson wrote:
> > I was having a problem with a bug in 1.1.3 of tomahawk/myfaces that
> > was fixed in 1.1.5 core, so I decided to upgrade to
> > 1.1.5/1.1.5-Snapshot. After the upgrade, many of my select controls
> > (selectOneRadio, selectOneMenu, etc.) are now broken. The cause is
> > that in 1.1.3 non-converted values were allowed, but in 1.1.5 they are
> > not.
> >
> > Example:
> >
> > <t:selectOneRadio value="#{bean.value}">
> > <f:selectItem itemValue="1" />
> > <f:selectItem itemValue="2" />
> > </t:selectOneRadio>
> >
> > public class MyBean {
> > private int value;
> > public int getValue() {return value;}
> > public void setValue(int value) { this.value = value; }
> > }
> >
> > In 1.1.3, this worked. In 1.1.5 this fails. The reason for the failure
> > is that in 1.1.5 it looks for a select item with value of Integer(1)
> > or Integer(2), but the select items contain "1" and "2". Since the
> > following are false:
> >
> > new Integer(1) == "1" && (new Integer(1)).equals("1")
> >
> > The validation always fails. This was a nice feature in 1.1.3, that
> > the item value of a select item can be a string representation that
> > the converter would take care of. Was this part of the JSF spec. and
> > 1.1.3 was not compliant, or was there another reason?
>
