1 2 Previous Next 25 Replies Latest reply on Oct 12, 2011 12:44 PM by ccerb

    rich:comboBox and rich:suggestionbox should support h:select

    vladimir.kovalyuk

      I believe the two mentioned components should be capable of replacing values with labels as and <h:selectOneMenu> does.
      Current implementation limits their use, for instance they can't act as entity selectors in conjunction with <s:selectItems> and <s:convertEntity>.
      I don't see a work around the problem.

      Hmm, it seems that when both label and value would be used, suggestion box should be capable to disallow editing wrong labels in attached editor. Either empty text or valid label should be selected as the result of user activity.

        • 1. Re: rich:comboBox and rich:suggestionbox should support h:se
          vladimir.kovalyuk

          I believe the two mentioned components should be capable of replacing values with labels as and <h:selectOneMenu> does.
          Current implementation limits their use, for instance they can't act as entity selectors in conjunction with <s:selectItems> and <s:convertEntity>.
          I don't see a work around the problem.

          Hmm, it seems that when both label and value would be used, suggestion box should be capable to disallow editing wrong labels in attached editor. Either empty text or valid label should be selected as the result of user activity.

          • 2. Re: rich:comboBox and rich:suggestionbox should support h:se
            vladimir.kovalyuk

            I believe the two mentioned components should be capable of replacing values with labels as &lt;select&rt; and &lt;h:selectOneMenu&rt; does.
            Current implementation limits their use, for instance they can't act as entity selectors in conjunction with <s:selectItems> and <s:convertEntity>.
            I don't see a work around the problem.

            Hmm, it seems that when both label and value would be used, suggestion box should be capable to disallow editing wrong labels in attached editor. Either empty text or valid label should be selected as the result of user activity.

            • 3. Re: rich:comboBox and rich:suggestionbox should support h:se
              vladimir.kovalyuk

              sorry for flooding
              I didn't expect that the engine passes html tags through even when 'Disable HTML' is checked.

              • 4. Re: rich:comboBox and rich:suggestionbox should support h:se
                jbalunas

                np with the flooding happens to the best of us ;-)

                "vladimir.kovalyuk" wrote:
                I believe the two mentioned components should be capable of replacing values with labels as <select&rt; and <h:selectOneMenu&rt; does.
                Current implementation limits their use, for instance they can't act as entity selectors in conjunction with <s:selectItems> and <s:convertEntity>.
                I don't see a work around the problem.


                I think this makes sense to me - could you enter a jira for this request?


                Hmm, it seems that when both label and value would be used, suggestion box should be capable to disallow editing wrong labels in attached editor. Either empty text or valid label should be selected as the result of user activity.


                I'm not sure I'm following you - could you show a brief example?

                • 5. Re: rich:comboBox and rich:suggestionbox should support h:se
                  vladimir.kovalyuk

                  Done, https://jira.jboss.org/jira/browse/RF-5046

                  My undestanding is when <h:suggestionbox> would be capable to work with labels, it should call a setter and pass translated value. Since the user is able to just enter any label it would leads to cases when there wouldn't be a corresponding value. That case should be gracefully handled.
                  At that i suggest a mode, where a client side code of component would erase inputText in case when user typed a label for which corresponding value does not exist. Say it would happend on onblur event. If suggestionbox is active then inputText should be filled with currently selected item's label. Suggestionbox should always have selected item.

                  consider the following component
                  <h:highlightedOutputText value="#{item.name}" highlightedText="#{input.value}" />
                  I think it would help to render suggestionbox with highlighted matched part.

                  • 6. Re: rich:comboBox and rich:suggestionbox should support h:se
                    ilya_shaikovsky

                    Sorry but this jira request will be rejected for sure. ComboBox designed from the beggining as input component. Select Items support added only for declarative definitions of suggestion strings.

                    So you could rise a request for completelly new component.

                    • 7. Re: rich:comboBox and rich:suggestionbox should support h:se
                      ilya_shaikovsky

                      The point that the components is input ones - was planned from the beggining and was available for the community. As for me it's a bad practice to add not native functionality to already existent components.

                      So if you need some rich selects this should be discussed explicitly.

                      • 8. Re: rich:comboBox and rich:suggestionbox should support h:se
                        vladimir.kovalyuk

                        That's ok for rich:suggestionbox, it is great component to build search-like interfaces. Hovewer support of <f:selectItem> confuses me, because it is oddly partial.

                        I can't agree that rich:combobox is an input component only. I used to think that combobox is a component where the user selects an option.

                        I don't think Richfaces shoud introduce a brand new component for select scenarios. Making combobox select component would be enough.

                        • 9. Re: rich:comboBox and rich:suggestionbox should support h:se
                          ilya_shaikovsky

                          I understand your position.. But I do not tell you that you are wrong.. I'm tell you that this concrete components probably has bad name but this just input component by design and requirements. It was requested as client side suggestionBox. :) f:selects support was introduced just as small feature. Main case for the component data definition is suggestionValues value binding to the list of Strings.

                          • 10. Re: rich:comboBox and rich:suggestionbox should support h:se
                            vladimir.kovalyuk

                            Okay, go ahead with a brand new component.

                            • 11. Re: rich:comboBox and rich:suggestionbox should support h:se
                              vladimir.kovalyuk

                              Okay, go ahead with a brand new component.

                              • 12. Re: rich:comboBox and rich:suggestionbox should support h:se
                                silverjam

                                Sorry, but I just don't understand the concept of having an input field that has a number of texts to select between, when the user can write a completely different text that doesn't exist in the list! -- It would be a nice feature, but not one that I would ever want. Give me a single valid example for this?!!!

                                At least the component should support showing the labels on the SelectItems, if a label is defined. If no label is defined, it should just show the id.

                                If you would really want to be able to enter text that doesn't exist in the list, it could be to add an extra boolean property called something like "onlyAllowListedValues".

                                I don't care if another control is created. This control is useless and noone will ever use it. Sorry.

                                Any feedback?

                                ~Morten :-)

                                • 13. Re: rich:comboBox and rich:suggestionbox should support h:se
                                  ilya_shaikovsky

                                   


                                  I don't care if another control is created. This control is useless and noone will ever use it. Sorry.


                                  The number of guys voted for client side suggestions input telling about the other result. And number of posts at the user forum also. Our points already listed above.

                                  • 14. Re: rich:comboBox and rich:suggestionbox should support h:se
                                    nbelaevski

                                     

                                    "silverjam" wrote:
                                    Sorry, but I just don't understand the concept of having an input field that has a number of texts to select between, when the user can write a completely different text that doesn't exist in the list! -- It would be a nice feature, but not one that I would ever want. Give me a single valid example for this?!!!

                                    See how Wikipedia defines combo boxes: http://en.wikipedia.org/wiki/Combo_box

                                    1 2 Previous Next