Hmmm. I must be missing something. Other than parameterization, including
your use of disable and null values, I don't see any significant differences
(I also tried moving the converter into the h:selectOneMenu - no effect). In
fact, the Tomahawk example uses "" as a nothing -selected value, just as we
do. And the converter code is essentially identical - we start with:
if( string == null || string.trim().length() == 0 )
return null;
So why are we getting an exception during the validation phase?
Bob
Mike Kienenberger wrote:
>
> Here's how the tomahawk examples do it:
>
> <h:selectOneMenu id="selone_menu_colors"
> value="#{carconf.color}" styleClass="selectOneMenu"
> converter="#{carconf.colorConverter}">
> <f:selectItem itemValue=""
> itemLabel="#{example_messages['empty_selitem']}" />
>
>
>
> public Object getAsObject(FacesContext facesContext,
> UIComponent component, String string) throws ConverterException
> {
> if(string==null)
> return null;
>
>
> Here's how I do it on my own projects:
>
> public final static String DISABLED_OPTION_VALUE =
> "com.xyz.utilities.web.jsf.converter.DISABLED_OPTION_VALUE";
> public final static String NULL_OPTION_VALUE =
> "com.xyz.utilities.web.jsf.converter.NULL_OPTION_VALUE";
>
> public String getNullSelectItemOptionValue() {
> return
> com.xyz.utilities.web.jsf.converter.ConverterOptions.NULL_OPTION_VALUE;
> }
>
> <f:selectItem
> itemValue="#{myPage.nullSelectItemOptionValue}"
> itemLabel="<No selection>" />
>
> public Object getAsObject(FacesContext context, UIComponent
> component, String value) throws ConverterException
> {
> if (null == value) return null;
> if (ConverterOptions.DISABLED_OPTION_VALUE.equals(value)) return
> null;
> if (ConverterOptions.NULL_OPTION_VALUE.equals(value)) return
> null;
>
> On 3/30/07, fastbob <[EMAIL PROTECTED]> wrote:
>>
>>
>> Mike Kienenberger wrote:
>> >
>> > Yes, that's how I would do it. If you specify an itemValue, then that
>> > value must be of the correct type. Ie, " " is not a containerType
>> > (Srinivas) and "0" is not a region (Carl).
>> >
>> Ouch. The assumption is that there is a one-one correspondence between
>> the
>> list items and the type in the model. This isn't always the case.
>>
>> We had a number of JSP's under 1.1.3 with the following sequence, for
>> several different types of lists:
>>
>> <h:selectOneMenu id="client" value="#{myPage.projectType}">
>> <f:converter converterId="x.y.ProjectTypeConverter"/>
>> <f:selectItem itemValue="" itemLabel="--- Select Project
>> Type---"/>
>> <f:selectItems value="#{myPage.projectTypeList}"/>
>> </h:selectOneMenu>
>>
>> The values in the type are fixed (essentially an enumeration, but not
>> implemented that way), and there is no "empty" value available. Instead,
>> if
>> the converters are passed a null or empty string for conversion to the
>> underlying type, they immediately return null. So in this case null is
>> used
>> to indicate no value has been selected by the user, and they get an
>> error.
>>
>> With 1.1.5, we get the following exception:
>>
>> java.lang.ClassCastException: java.lang.String cannot be cast to
>> javax.ejb.EJBLocalObject
>> at
>> org.jboss.ejb.plugins.local.LocalProxy.isIdentical(LocalProxy.java:124)
>> at
>> org.jboss.ejb.plugins.local.LocalProxy.invoke(LocalProxy.java:174)
>> at
>> org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:40)
>> at
>> org.jboss.ejb.plugins.local.LocalProxy.invoke(LocalProxy.java:155)
>> at
>> org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:40)
>> at $Proxy262.equals(Unknown Source)
>> at
>> javax.faces.component._SelectItemsUtil.matchValue(_SelectItemsUtil.java:65)
>> at
>> javax.faces.component.UISelectOne.validateValue(UISelectOne.java:56)
>> at javax.faces.component.UIInput.validate(UIInput.java:354)
>> at
>> javax.faces.component.UIInput.processValidators(UIInput.java:184)
>> […]
>>
>> Here are the relevant lines from _SelectItemsUtil.MatchValue():
>>
>> [item is class SelectItem]
>> Object itemValue = item.getValue();
>> if (value==itemValue || value.equals(itemValue))
>>
>> The exception is thrown by the call to equals in an EJB.
>>
>> I haven't come up with a low-cost way to fix this.
>>
>> Bob
>> --
>> View this message in context:
>> http://www.nabble.com/ERROR%3A-Value-is-not-a-valid-option-tf3270984.html#a9762021
>> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/ERROR%3A-Value-is-not-a-valid-option-tf3270984.html#a9762503
Sent from the MyFaces - Users mailing list archive at Nabble.com.
