ICEfaces
  1. ICEfaces
  2. ICE-7818

New ace:autoCompleteEntry component

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.1.0.BETA2, 3.1
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      ICEfaces 3, ACE Components
    • Assignee Priority:
      P1
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial

      Description

      Add a new ace:autoCompleteEntry component.

      Key Features include:

      - Ability to display simple and compound content in the popup list (simple value string list or JSF facet content for each row)
      - Support an internal data model for select options
      - Configurable options include: millisTypingDelay before submit, min chars before submit, case insensitivity, match criteria (startsWith (default) or match anywhere)
      - Optionally display button to use a combo-box. Clicking button will display list of possible matches, even without any chars entered.
      - Popup list direction attribute to force popup direction, otherwise uses auto positioning logic (like ace:subMenu).
      - Ability to set the popup list height value which will provide a vertical scrollbar in the pop-list if necessary to display the number of rows being displayed.

        Issue Links

          Activity

          Hide
          Arturo Zambrano added a comment -

          Some of the challenges faced when developing this component were the following:

          • The Javascript code from the ice.selectInputText component had to be ported to the ACE environment. The original code was making heavy use of the Prototype and Scriptaculous libraries, so it had to be ported without using these libraries and using equivalent jQuery functions and utilities instead. Some features were straight forward to translate into ACE, but other features required a more in-depth investigation to make sure that their effects would be the same, and not more and not less, in this new component. Other third-party autocomplete widgets were considered (e.g. jQuery UI Autocomplete), but they didn't offer the same level of flexibility and adaptability to JSF that we already had in the code used for ice:selectInputText.
          • The ice.selectInputText component supported rendering the rows of the list via a facet. However, this relied on the rendering technique used in ICEfaces 1.8.x and earlier versions. This technique consists in creating a DOM tree using corresponding Java objects for each node (HTML elements, text nodes, etc.), which allows to make changes to what has been rendered at any point during the rendering phase before sending the response to the client. Since, the rendering technique used in ICEfaces 2.0 and later versions is more direct and doesn't allow to make changes to what has been rendered, a different approach to support rendering via a facet had to be implemented for this new component, which also had an impact in the client-side code.
          • The ice.selectInputText component didn't have auto-filtering functionality. It relied on the application code to filter the results to be sent to the user. In this new component, that job is done by the component code itself for the most common filtering modes (startsWith, endsWith, contains, and exact). This had to change the paradigm used in the ice.selectInputText component. While the old component needed the application developer to provide the list of final results, which would be shown entirely to the user, this new component only needs to have access to the list that contains all the possible results, since it will filter them and only show relevant options to the user, freeing the application developer from doing any processing on this list. This had an impact in many areas of the server-side code, since it was always assumed that the list provided by the application developer would be definite and no further processing was necessary. This component still had to offer the flexibility of doing any custom filtering and lazy loading of results if the application developer wishes to.
          • The ice.selectInputText component only accepted lists of SelectItem objects, and only their label and value properties could be used. This new component accepts any arbitrary data object (i.e. POJO) when rendering via a facet, so it is possible to render different properties of an item in each row like the name of a city and also the name of the country it is in, for example. This also had an impact in most of the server-side code, since it was assumed by all methods that all elements in the list would be instances of SelectItem, so substantial changes had to be made throughout the component and renderer code to support arbitrary data objects.
          Show
          Arturo Zambrano added a comment - Some of the challenges faced when developing this component were the following: The Javascript code from the ice.selectInputText component had to be ported to the ACE environment. The original code was making heavy use of the Prototype and Scriptaculous libraries, so it had to be ported without using these libraries and using equivalent jQuery functions and utilities instead. Some features were straight forward to translate into ACE, but other features required a more in-depth investigation to make sure that their effects would be the same, and not more and not less, in this new component. Other third-party autocomplete widgets were considered (e.g. jQuery UI Autocomplete), but they didn't offer the same level of flexibility and adaptability to JSF that we already had in the code used for ice:selectInputText. The ice.selectInputText component supported rendering the rows of the list via a facet. However, this relied on the rendering technique used in ICEfaces 1.8.x and earlier versions. This technique consists in creating a DOM tree using corresponding Java objects for each node (HTML elements, text nodes, etc.), which allows to make changes to what has been rendered at any point during the rendering phase before sending the response to the client. Since, the rendering technique used in ICEfaces 2.0 and later versions is more direct and doesn't allow to make changes to what has been rendered, a different approach to support rendering via a facet had to be implemented for this new component, which also had an impact in the client-side code. The ice.selectInputText component didn't have auto-filtering functionality. It relied on the application code to filter the results to be sent to the user. In this new component, that job is done by the component code itself for the most common filtering modes (startsWith, endsWith, contains, and exact). This had to change the paradigm used in the ice.selectInputText component. While the old component needed the application developer to provide the list of final results, which would be shown entirely to the user, this new component only needs to have access to the list that contains all the possible results, since it will filter them and only show relevant options to the user, freeing the application developer from doing any processing on this list. This had an impact in many areas of the server-side code, since it was always assumed that the list provided by the application developer would be definite and no further processing was necessary. This component still had to offer the flexibility of doing any custom filtering and lazy loading of results if the application developer wishes to. The ice.selectInputText component only accepted lists of SelectItem objects, and only their label and value properties could be used. This new component accepts any arbitrary data object (i.e. POJO) when rendering via a facet, so it is possible to render different properties of an item in each row like the name of a city and also the name of the country it is in, for example. This also had an impact in most of the server-side code, since it was assumed by all methods that all elements in the list would be instances of SelectItem, so substantial changes had to be made throughout the component and renderer code to support arbitrary data objects.
          Hide
          Ken Fyten added a comment - - edited

          Need to complete the following additional features:

          • Configurable options include: millisTypingDelay before submit, min chars before submit, case insensitivity, match criteria (startsWith (default) or match anywhere)
          • Ability to set the popup list height value which will provide a vertical scrollbar in the pop-list if necessary to display the number of rows being displayed.
          • Popup list direction attribute to force popup direction, otherwise uses auto positioning logic (like ace:subMenu).
          • Popup list needs to support ThemeRoller styling (can match dialog or ace:list usage), rounded corners, etc.
          Show
          Ken Fyten added a comment - - edited Need to complete the following additional features: Configurable options include: millisTypingDelay before submit, min chars before submit, case insensitivity, match criteria (startsWith (default) or match anywhere) Ability to set the popup list height value which will provide a vertical scrollbar in the pop-list if necessary to display the number of rows being displayed. Popup list direction attribute to force popup direction, otherwise uses auto positioning logic (like ace:subMenu). Popup list needs to support ThemeRoller styling (can match dialog or ace:list usage), rounded corners, etc.
          Hide
          Arturo Zambrano added a comment -

          Added 'delay', 'minChars', 'caseSensitive', 'height', and 'direction' attributes.

          Fixed several issues as part of ICE-8137 and ICE-8183.

          Show
          Arturo Zambrano added a comment - Added 'delay', 'minChars', 'caseSensitive', 'height', and 'direction' attributes. Fixed several issues as part of ICE-8137 and ICE-8183 .
          Hide
          Arturo Zambrano added a comment -

          Removed borders from individual results in the list (revision 29754).

          Show
          Arturo Zambrano added a comment - Removed borders from individual results in the list (revision 29754).

            People

            • Assignee:
              Arturo Zambrano
              Reporter:
              Ken Fyten
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: