selectManyListbox' value attribute

[Russell Bateman]

I'm trying to clean up warnings on my working pages in a simple JSF application. In particular, my <h:selectManyListbox ...> instances all behave perfectly, but Eclipse marks my .jsp with a warning (hmmm... I hope this isn't an Eclipse thing and I've gone and asked the question of the wrong forum?):

Cannot coerce type java.lang.String[] to java.lang.String, java.lang.Short, java.lang.Character, java.lang.Boolean, java.lang.Double, java.lang.Byte, java.lang.Long, java.lang.Float, java.lang.Integer

The warning occurs each time on line 2 (presumably because of the value attribute):

<h:selectManyListbox title="#{msg['query.language_prompt']}"
                     value="#{queryBean.languages}">
    <f:selectItems value="#{queryBean.languageItems}" />
</h:selectManyListbox>

Now, QueryBean.java, relevant to languages, appears thus:

    private String[]                               languages     = null;
    private static LinkedHashMap< String, String > languageItems = null;
    .
    .
    .
    public String[]              getLanguages()    { return this.languages;     }
    public Map< String, String > getLanguageItems(){ return languageItems;      }

Everywhere in examples on the Internet, I see String[] used as the type of what goes in the value attribute. In fact, given it's potentially multiple items, it doesn't sound reasonable it could ever be any of those other, "scalar" types. Why then would the JSP validator issue this warning? Am I missing something? Can I do nothing other than just ignore the warning?

Thanks for any and all elucidation.

Russ Bateman

[Tim Holloway]

The EL processor and BeanUtils have absolutely no problem with backing web pages with non-string datatypes. In fact, that's one of the primary things that BeanUtils provides.

However, your real problem is that a SelectMenu has to get its options in the form of a SelectItem collection, not a raw array or collection. SelectItem provides the wrapper that allows a property value to be paired with a human-friendly select option label. Or, if you're not friendly, it just uses the value as the label, but in either case, the SelectItems are each pairs of label/value items, where the label is a string, and the value can be of any supported datatype - String, Integer, Shurt or whatever.

[Russell Bateman]

Okay, I knew I was somewhat confused on this point and I saw elsewhere, as I say, examples only using String[], which made sense to me.

What I'm really supposed to pass is a SelectItem[] that would appear thus (I'm an old C programmer, so humor and correct me please):

class SelectItem /* is (among whatever else it might be) */ { Object value; String label; }

// what I'm passing...
String[]:
{
    { "English" },
    { "French" },
    { "German" },
    {  etc.
};

// what I should pass...
SelectItem[]:
{
    { ( Object ) 0, "English" },
    { ( Object ) 1, "French" },
    { ( Object ) 2, "German" },
    { ( Object ) 3, etc.
}

Is this right?

I'm surprised my String[] works at all. And, as only care about the labels, I think, I wonder what to pass as the property value, an integer (as illustrated here) or maybe another string like "en", "fr", "de"?

I know my code throbbed several times including SelectItem[] at one point, but in the end when I got it working, the right sort of object had disappeared. This was, as I say, under the influence of a number of tutorials I was using to help me past problems I was having using Geary/Horstmann (not blaming them, just saying their example for <h:selectManyListbox...> wasn't close enough to what I was trying to do or, at least, I wasn't seeing it that way).

Thanks, Tim, for your answer as well as for any additional comments I hope you'll make.

Russ

[Tim Holloway]

A SelectItem when rendered via the HtmlRenderer comes out as:

<option value="value">Label</value>

Actually, there may be a difference for the list options on SelectManyListBox that I'm not aware of, since I have never used it, but for SelectOneListBox, you used to get thumped for passing an an array or collection directly. Unless they've relaxed the restriction in a later version. In some ways it's harder to keep up with changes to existing resources than to learn entire new ones, so a lot of times I only discover stuff like that if I had to RTFM on something.

Speaking of changes, the original of your example could have been coded as:

SelectItem[] items =  
{  
   new SelectItem(new Integer(0), "English" ),  
   new SelectItem(new Integer(1), "French" ),  
   new SelectItem(new Integer(2), "German"),  
}  ;

However, the auto-boxing feature that came into play in Java 1.5 allows you to alternatively code it like so:

SelectItem[] items =  
{  
   new SelectItem(0, "English"),  
   new SelectItem(1, "French"),  
   new SelectItem(2, "German"),  
}  ;

The results are the same. For other types such as Short, Byte, or Long, you'd have to use an explict wrapper constructor. Well, except for Long, where "1L" gives the same effect.

[Russell Bateman]

Thanks. This is really very useful stuff.

My experiences with <selectOneListbox ...> have gone identically--in other words they've worked this way too. At some point very soon I'm going to revisit this SelectItem code to redo it.

I intend to publish a tutorial on this because there's not enough in the space between tiny tutorials that teach nothing but the practical and great books that teach the theory, but gloss over the practical. I was going to avoid that, but I've amassed so many useful notes and answered so many questions on it that I think it's probably time. And, as I told one guy in an Eclipse forum this morning, "I write to prove to myself that I grok."

Best regards to you,

Russ

[Tim Holloway]

Erratum:

<option value="value">Label</option>