It was answered a couple of times already. We designed this component as input with client side suggestions. So objects handling out of scope of this component. You could use objects in theory but you should write your own converter in this case.
Are there any plans to design it to make it works with objects?
A lot of functionality is lost with simple strings.
Seam provides converter for JPA entities. You could have a look at its implementation. If you plan to use non-JPA objects it wouldn't be very difficult to design your own - you would need to create two classes - converter itself and page-scoped store of pairs (Object, String) to transform object identity to string and vice-versa.
We have recently implemented it in our application which uses Richfaces 3.3.x. Create a list of SelectItem and set to as you do for h:selectOneMenu.
You can see label is shown as expected.
2nd thing - you need to pass the value to backing bean and retrive the value along with description while displaying on the screen..
For this you need to write a converter and implement getAsObject and getAsString method. Implementing getAsObject in this case is easy. All you need to substring the value part and return. In the getAsObject you need to get the list of items using BeanUtils.getSelectItems(UIComponent) and get the selected item label and return it.
Note:- when the list is huge like 2000 or 3000 or above I can see a delay in rendering the list. Otherwise its pretty fast.
I can post the sample code if anyone interested.
This issue has been popping up many times in the last several months. People are simply confused by the name of the component and how it is presented on the UI. I personally came across this with my team on a project where we didn't have the privilege of using Seam, and had to change some of the key design aspects and add a lot of code.
The whole concepts of component based UI is to make it easier and faster to assemble enterprise application. When there are many voices calling for certain functionality it would be unwise to ignore them. Clearly there is demand for a component that acts like h:selectOneMenu but allows to type things in. This is what in a lot of desktop dev environments was called a combo box.
So, in order to be constructive, I'd like to suggest creating a new component that does just that. Ideally it would be called comboBox and what is currently the comboBox, could be called rich:inputSuggest.
Since the 3.3.x branch is heading for more of a maintenance mode now, RF 4.0 could be a good place to introduce this kind of component, which would add to the allure of JSF 2.0
What do you guys think?
@sujitkm: I for one wouldn't mind seeing your code. I'm running into this exact issue and I'm looking for the solution which it seems you have. This person also seems to have a similar solution:
rich:combobox does what it was designed to (an input text component with client-side suggestions).
If we want to use it for selecting of values based on selected labels (rendered by the component), we must wait for a new component to be designed (or design it)... or enhance it on the client-side (as I did)...
In this article I share my (working) approach:
So please test it and let me know what you think.
God bless you.
Thanks for the article - good catch about accented characters & regex matching RFC is cool too! I've created https://jira.jboss.org/browse/RF-8896 & https://jira.jboss.org/browse/RF-8895 issue to cover this.
As for the posted code, I think it can be improved a little by using $super variable (it's a Prototype.js stuff, provides access to the overridden method).
Talking about regex, what would be nice is that there were these types of search: begins with (default), contains, and contains any (regexp, where a separation token whould be provided, or default to space char, as in my regex). These search methods for suggestions could be set from an attribute, maybe searchMethod in the rich:comboBox tag. Also, there should be a JS API method to change it on the client-side.
On the JS side, I didn't want to use $super, because I changed the inner code of the functions, so calling the overriden ones would have been useful, I guess... Also, as I read, you're going to remove Prototype.js, so the $super variable would not be reachable, right?
I'll contribute these comments to the JIRA as well.
I just felt into the same hole. I really thought that ComboBox is a DropDown Box with suggestion capability. So, there is really a demand of having such a component out-of-the-box.
Please add this to Richfaces!
there is already rich:select planned for 4.x