Agree that combobox is not a solution for large number of suggestions bu not sure that udnerstand the problem with suggestion component, Could you please clarify a bit more?
The suggestion component behavior is required, but additional will not allow the end user to filter by many criteria.
To follow the earlier example, in the Company edit form I want to see and select from all Contacts that are from a specific Location, registered in the last Month (data range filters), name start with, income is > x (numbers filters), etc. All these need to be on a search popup div form.
I can make my baking bean to search in fields like first name, last name, location.name and auto-complete like suggestion component, but you might want to filter more.
When you have 10000 Contact records in a CRM sollution let's say and an impressive number of columns in the table to search and filter from, you definitely need a lookup component.
so still can't fully get the problem. if the suggestion is not ajax single, it will process all the filds on search form and you could return autocompletion list by all the criterias you have.
How do you see the search fields and the search form if you don't have a popup or toggle panel? The search fields are for the Foreign Related entity, not for the current Object Entity which is in edit mode.
Form 1 (Company)
---Field 1 Name
---Field 2 Code
---Field 3 Customer --> Select Customer Button (will trigger the popup lookup)
---Field 4 Location --> Another lookup button, which will open a new select window
Field 3 and Field 4 are lookup fields, no search criteria exist for them on the main Form 1.
PLUS: I need to paginate the results of the suggestion. One filter can still give me 1000 records...
You can see a good example here: http://download.oracle.com/docs/cd/E12839_01/web.1111/b31973/af_lov.htm
The utility of the component is beyond question, all decent desktop components are using this for years (Delphi was having a component like this).
MyFaces has a component like this: http://myfaces.apache.org/trinidad/trinidad-api/tagdoc/tr_inputListOfValues.html, but I don't really want to mix RichFaces with MyFaces in the same project and I don't want to reinvent the will by creating a component which I'm sure many are using and need it (in a form or another).
Thanks for your efforts and patience. I think you could fill jira request on such component for future.
But I still believe that you could construct the component using richfaces using creation custom facelet. Modal panel could be used to popup additional search panels, fields inside will be criteria fields, and there is no problem to update main page from the MP after the selection/search requests. At least the second myFaces sample you shown(I checked their demo on the component) - could be easilyy implemented using such approach.
One additional difficulty when thinking of such components implementations is reusability point. Business applications design and some functional requirements could differs in many points between applications and such complex composite component is very difficult to create in such way that it will be really reusable between different designs and business requirements. So that's why sometimes we reject component creation approach and prefer to suggest composition facelets creation in such cases.
Actually, I found a jira issue with the resolution rejected: https://jira.jboss.org/jira/browse/RF-3565
This is why I was sure that there are alternatives used by other forum users.
I'm agree that is difficult to make analysis for such a component, but having features like this will sure count in the decision of choosing a JSF framework.
B.t.w. we will use the jira instead of wiki for such request so I will reopen it. Add your vote there.
Thanks! It has my vote