Not really sure how much more I can add. I've posted examples of
similar code I have, but without seeing a simplified (but erroring)
example demonstrating why your setup isn't working, I'm not sure what
else to suggest. getAsObject has to return a homogenious set of
objects. But as long as your converter translates the string values,
I think you can have a heterogenious collection of SelectItem
itemValues fed into the renderer. I know I've mixed marker Strings
(representing null and disabled selections) with actual
ProjectTypeLocal-esque objects on my page code.
On 4/2/07, fastbob <[EMAIL PROTECTED]> wrote:
Usually the selectItem values are EJB's, but in a couple of instances they
strings that just happen to be the serialized form of the EJB. The
prototypical code looks like:
ArrayList projectTypes = new ArrayList( projectTypeHome.findAll()
);
for( int i = 0; i < projectTypes.size(); i++ )
{
ProjectTypeLocal projectType =
(ProjectTypeLocal)projectTypes.get( i );
m_projectTypes.add( new SelectItem( projectType,
projectType.getName() ) );
}
What this means is when we get to the following lines in _SelectItemsUtil,
the equals() method of the EJB is called with the empty ("") string (in
1.1.5):
[item is class SelectItem]
Object itemValue = item.getValue();
if (value==itemValue || value.equals(itemValue))
It appears that the 1.1.3 code handled the case of any String being passed.
Since our converters look for an empty string, this results in the EJB
equals() being passed null:
Object itemValue = item.getValue();
if(converter != null && itemValue instanceof String)
{
itemValue = converter.getConvertedValue(context,
(String)itemValue);
}
if (value==itemValue || value.equals(itemValue))
But I guess this circles back to non-standard conversion that was taken out.
I'm pretty ignorant of all the JSF lifecycle semantics, but since this
practice is always used with required="true", would an earlier check for a
non-null, non-empty string fix this?
I'm open to suggestions.
Mike Kienenberger wrote:
>
> Yes, I think you're right. It's not the form String -> Object that's
> causing the issue.
> It looks like it's the contents of the selectItem values. What are
> you initializing the selectItem value fields with?
>
> What's the contents of selectItem.value when it's of type String?
>
> On 3/30/07, fastbob <[EMAIL PROTECTED]> wrote:
>>
>> 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.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/ERROR%3A-Value-is-not-a-valid-option-tf3270984.html#a9797466
Sent from the MyFaces - Users mailing list archive at Nabble.com.
