You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Andrew Robinson <an...@gmail.com> on 2007/03/14 21:56:32 UTC
SelectItem compatibility was broken from 1.1.3 to 1.1.5?
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?
Thanks,
Andrew
Re: SelectItem compatibility was broken from 1.1.3 to 1.1.5?
Posted by Mike Kienenberger <mk...@gmail.com>.
I've been answering this question a lot recently.
There's nothing in the spec that allows us to coerce from one type to
another for f:selectItem.
4.1.13.2 Properties
The server-side value of this item, of the same
basic data type as the parent component's
value. If the parent component type's value is a
value binding expression that points at a
primitive, this value must be of the
corresponding wrapper type
However, we could allow such a coercion for t:selectItem.
Another workaround that might help is using "#{1}" instead of "1"
On 3/14/07, Andrew Robinson <an...@gmail.com> 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?
>
> Thanks,
> Andrew
>
Re: SelectItem compatibility was broken from 1.1.3 to 1.1.5?
Posted by Andrew Robinson <an...@gmail.com>.
I'll just write my own select item, thanks.
On 3/14/07, Mike Kienenberger <mk...@gmail.com> wrote:
> 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 <an...@gmail.com> 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 <si...@rhe.co.nz> 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?
> > >
> >
>
Re: SelectItem compatibility was broken from 1.1.3 to 1.1.5?
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <an...@gmail.com> 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 <si...@rhe.co.nz> 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?
> >
>
Re: SelectItem compatibility was broken from 1.1.3 to 1.1.5?
Posted by Andrew Robinson <an...@gmail.com>.
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 <si...@rhe.co.nz> 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?
>
Re: SelectItem compatibility was broken from 1.1.3 to 1.1.5?
Posted by Simon Kitching <si...@rhe.co.nz>.
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?