7 Replies Latest reply on Sep 20, 2011 7:01 AM by Brendan Healey

    rich:autocomplete or a new component?

    Cody Lerum Apprentice

      Often in my application I have edit pages for a specific enitity and I need to edit the non-collection side of a ManyToOne association. My prefered way of doing this is to use a autocomplete component backed by a search method using hibernate search.

       

      In RF 3 I accomplished this with a mess like this.

       

      <s:div id="siteDiv">
                <a:region>
                          <s:decorate template="/layout/view.xhtml" rendered="#{ticket.site != null}">
                                    <ui:define name="label">Site:</ui:define>
                                    <h:outputText value="#{ticket.site.toString()}" converter="stringTrim30" />
                                    <h:outputText value=" :: "/>
                                    <span class="actionLinks">
                                              <a:commandLink value="Clear" action="#{ticketUtil.updateSite(null)}" rendered="#{ticketTools.allowSiteEdit(ticket)}" reRender="associationsDiv" />
                                    </span>
                          </s:decorate>
                          <s:decorate template="/layout/edit.xhtml" rendered="#{ticket.site == null}">
                                    <ui:define name="label">Site:</ui:define>
                                    <h:inputText id="site" size="50" required="false" tabindex="5"/>
                                    <rich:suggestionbox for="site" suggestionAction="#{siteLists.searchSites}" var="_site" minChars="2" id="suggestion" width="500" nothingLabel="No Sites Found">
                                              <h:column>
                                                        <h:outputText value="#{siteTools.getFullName(_site)}" /> 
                                              </h:column>
                                              <a:support ajaxSingle="true" action="#{ticketUtil.updateSite(_site)}" event="onselect" reRender="associationsDiv"/>
                                    </rich:suggestionbox> 
                          </s:decorate>
                </a:region>
      </s:div>
      

       

      As I'm going through RF4 I'm not quite sure how to accomplish the same thing. The requirements would be:

       

      1. POJO support. The backing value should be an object #{ticket.site} but there should be a label #{site.displayName}

       

      2. Force selection. If the user types in "Monkey" and that doesn't match anything to bring up a result in the suggest drop down then "Monkey" should be cleared from the input on blur. Also if something did match and was selected then adding new characters to the input should null the value and execute the search method for more.

       

      3. Read only. In conjuntion with 2 I would probably want to set the component as read only after a value was selected so that the user cannot type in the field anymore readOnly="#{ticket.site != null}". I would then use an a:commandbutton or similar to set the ticket.site = null if I wanted to edit it again.

       

      Primefaces does this in 3.0

       

      <p:autoComplete id="entity" readonly="#{_contact.appEntity != null}" forceSelection="true" value="#{_contact.appEntity}" var="_ae" itemLabel="#{_ae.name}" itemValue="#{_ae}" completeMethod="#{entitySearch.appEntity}" converter="appEntityConverter" /> 
      

       

      Is this possible in RF4? If something is missing can it be added to the existing rich:autocomplete?

        • 1. Re: rich:autocomplete or a new component?
          Brian Leathem Master

          The fact that this doesn't work with POJO's seems like an omission to me.  Issue RF-11332 [1] addresses correcting this.

           

          [1]: https://issues.jboss.org/browse/RF-11332

          • 2. Re: rich:autocomplete or a new component?
            Brendan Healey Master

            Hi, I'm just porting to RF4 and the lack of pojo support in autoComplete has been the only real

            showstopper I've encountered. I'm writing a custom autocomplete component at the moment and

            would be happy to post the code up when it's ready in a few days. Although it won't be specifically

            targetted to your requirements it should be very easy to adapt, and I don't mind spending a little time

            on this.

             

            I won't be using the CDK at this point, although I do intend to investigate this soon.

             

            Regards,

            Brendan.

            • 3. Re: rich:autocomplete or a new component?
              Ilya Shaikovsky Master

              I still think that should be usage (with further improvements if needed) of <r:select> and not for <r:autocomplete>. We split suggestion box to two components initially to have different entities for different use-cases. autocomplete - input component and the second is select component.

               

              When we tried to add objects selection to RF 3 suggestion box it added really much of mess(you could check at least RF-demo it's already has not pretty straightforward usage) because the input component itself does not supposed to know about anything except the value in input. And all the rest value transformation should be made at converter level.

               

              There are next concerns about addition of the select functionality to input:

              • how did you know if the component uses its input to store value or label? (that's why we split them to clearly define responsibilities).
              • how will you process the situation when the typed string has no value assosiated (it's input and not a select so there could be anything)
              • the functionality itself will not be really straightforward as autocompelte supports multiple values of any kind separated by token, so what should be stored if the string in input is "aaa, bbb, , ,sss" ("," - token)
                • Problem 1 - what to store if only "aaa" has value assosiated with it.
                • Problem 2 - to which type you will bind value to store that multiple choises in general?
              • 4. Re: rich:autocomplete or a new component?
                Ilya Shaikovsky Master

                And what we planned to do earlier -

                • to add more rich functionality to r:select
                  • add custom popup content
                  • add multiple columns support
                  • ...
                • to add similar selectMany later (That's definitelly what him asking)
                  • and make it work like jira "versions"fields for example.
                • 5. Re: rich:autocomplete or a new component?
                  Cody Lerum Apprentice

                  rich:select would also need an "autocompleteMethod" so you could fetch suggestion values based on input.

                   

                  Otherwise I think you are on the exact right path with the jira version by

                   

                  1. Allowing input via typing to suggest values

                  2. only selection of suggested values

                  3. a way to clear the selected value(s) in the field easily.

                   

                  As long as there is an event we can listen for so that we can send the value back to the bean via ajax on selection as I usually need to rerender parts of the page after selection and conditionally render components based on the value which was selected.

                  • 6. Re: rich:autocomplete or a new component?
                    Cody Lerum Apprentice

                    Brendan,

                     

                    Have you had a chance to get your custom autocomplete working? I may be in the same boat shortly and don't want to reinvite the entire wheel.

                    • 7. Re: rich:autocomplete or a new component?
                      Brendan Healey Master

                      Hi Cody, yes I've got something working. I've only tested it with a single form in the view and using

                      h:form prependId="false". Also I use @ViewAccessScoped provided by Myfaces CODI, so whether it

                      would work with regular @RequestScoped I couldn't say. The major potential limitation at present is

                      that you MUST have a converter. Whatever is needed it shouldn't be too much trouble to get it working

                      for you.

                       

                      On the positive side you can use a converter and (for example) itemLabel="#{var.name}"

                      itemValue="#{var}", it supports nested f:ajax & you can have a valueChangeListener attribute. I

                      managed to get the javascript code so you can use the up/down arrow keys with focus in the input

                      to scoll down the select list and select a value using enter. I've tested it on IE8 and Chrome

                      14.0.835.163.

                       

                      If there's anything that doesn't match your use cases I can make changes as necessary, or

                      you could, however you wish.

                       

                      I've got some other work I've got to do today, I'll get some code posted tomorrow and you can run it up

                      and see how it meets your requirements.

                       

                      Regards,

                      Brendan.