ICEfaces
  1. ICEfaces
  2. ICE-8876

ace:autoCompleteEntry, add textChange event, only fire valueChange event on definite inputs

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.3
    • Component/s: None
    • Labels:
      None
    • Environment:
      Any
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.), Compatibility/Configuration

      Description

      At the moment, the valueChangeListener method is being fired every time a character is added or deleted from the text field. It even fires when pressing the up/down arrow keys. Instead, the valueChange event should only be triggered when the user gives a more definite input, which can be by either clicking on an option from the list, selecting an option from the list with the keyboard, or pressing the enter key on the text field. Additionally, a textChange event should be added, which will be triggered whenever the contents of the text field change before the user makes a clear decision about what the value of this component should be.

        Activity

        Hide
        Arturo Zambrano added a comment - - edited

        Committed improvement and other changes to the trunk at revision 33217.

        This is a list of changes and additions:

        • The value change event now only fires on hard submits (if there's a change). That is when the user gives a definite input, which occurs either when the user selects a value from the list by using the mouse or the keyboard, or when the user presses enter on the text field, or when the full form is submitted by other means.
        • As a corollary, the value property will only be set in such hard submit cases.
        • Added a new attribute textChangeListener. It will fire whenever the contents of the input field change (or other keys are pressed) before the user gives a more definite input (i.e. hard submit). Added a TextChangeEvent event to be used with this listener.
        • Fixed some minor issues when using the 'submit' ajax event: letting the bridge send an additional request when pressing 'enter' on the input field, and not displaying the list of possible results when pressing the arrow keys.
        • Prevented submission when pressing the tab key (unless a blur ajax event is registered).
        Show
        Arturo Zambrano added a comment - - edited Committed improvement and other changes to the trunk at revision 33217. This is a list of changes and additions: The value change event now only fires on hard submits (if there's a change). That is when the user gives a definite input, which occurs either when the user selects a value from the list by using the mouse or the keyboard, or when the user presses enter on the text field, or when the full form is submitted by other means. As a corollary, the value property will only be set in such hard submit cases. Added a new attribute textChangeListener. It will fire whenever the contents of the input field change (or other keys are pressed) before the user gives a more definite input (i.e. hard submit). Added a TextChangeEvent event to be used with this listener. Fixed some minor issues when using the 'submit' ajax event: letting the bridge send an additional request when pressing 'enter' on the input field, and not displaying the list of possible results when pressing the arrow keys. Prevented submission when pressing the tab key (unless a blur ajax event is registered).
        Hide
        Arturo Zambrano added a comment -

        Committed more changes at revision 33243.

        • Re-defined the 'textChange' event. It will only fire whenever the user adds or removes a character from the text field, but it won't fire when the user selects an option from the list or if the text changes by other means.
        • Added 'valueChange' and 'textChange' ajax events.
        • In order to avoid overlapping of ajax events. The 'submit' event will only fire if there are no 'valueChange' and/or 'textChange' events registered. In other words, the 'submit' event will fire in all cases where the 'valueChange' and 'textChange' events fire, but if there's a 'valueChange' registered as well, it won't fire in those cases. Likewise, if there's also a 'textChange' event registered, it won't fire in the cases of the 'textChange' event.
        • Prevented submission on keys that do not add or remove a character.
        Show
        Arturo Zambrano added a comment - Committed more changes at revision 33243. Re-defined the 'textChange' event. It will only fire whenever the user adds or removes a character from the text field, but it won't fire when the user selects an option from the list or if the text changes by other means. Added 'valueChange' and 'textChange' ajax events. In order to avoid overlapping of ajax events. The 'submit' event will only fire if there are no 'valueChange' and/or 'textChange' events registered. In other words, the 'submit' event will fire in all cases where the 'valueChange' and 'textChange' events fire, but if there's a 'valueChange' registered as well, it won't fire in those cases. Likewise, if there's also a 'textChange' event registered, it won't fire in the cases of the 'textChange' event. Prevented submission on keys that do not add or remove a character.
        Hide
        Arturo Zambrano added a comment -

        This is a table that compares the old behaviour and the new behaviour of the component.

        Action Old behaviour New behaviour
        Type a character Submit, fire valueChangeListener Submit, fire textChangeListener
        Remove a character (backspace or del) Submit, fire valueChangeListener Submit, fire textChangeListener
        Select a value from the list Submit, fire valueChangeListener Submit, fire valueChangeListener
        Press 'enter' on text field Submit, fire valueChangeListener Submit, fire valueChangeListener
        Press 'tab' key on text field Submit Do not submit
        Press any other key that doesn't add or remove a character Submit Do not submit
        Show
        Arturo Zambrano added a comment - This is a table that compares the old behaviour and the new behaviour of the component. Action Old behaviour New behaviour Type a character Submit, fire valueChangeListener Submit, fire textChangeListener Remove a character (backspace or del) Submit, fire valueChangeListener Submit, fire textChangeListener Select a value from the list Submit, fire valueChangeListener Submit, fire valueChangeListener Press 'enter' on text field Submit, fire valueChangeListener Submit, fire valueChangeListener Press 'tab' key on text field Submit Do not submit Press any other key that doesn't add or remove a character Submit Do not submit
        Hide
        Ken Fyten added a comment -

        Art, to clarify what is listed in the table above:

        "Type a character -> New behaviour -> Submit, fire textChangeListener" - the submit should only occur if an <ace:ajax event="textChange" /> exists in the component, correct? That is to say, there would be no submit unless the textChangeListener client event is registered?

        Show
        Ken Fyten added a comment - Art, to clarify what is listed in the table above: "Type a character -> New behaviour -> Submit, fire textChangeListener" - the submit should only occur if an <ace:ajax event="textChange" /> exists in the component, correct? That is to say, there would be no submit unless the textChangeListener client event is registered?
        Hide
        Arturo Zambrano added a comment -

        No, there has to be a submit anyway. The component needs to know which characters are in the text field in order to produce the list of possible results. The only scenario where this doesn't happen is when using the client side only mode.

        Show
        Arturo Zambrano added a comment - No, there has to be a submit anyway. The component needs to know which characters are in the text field in order to produce the list of possible results. The only scenario where this doesn't happen is when using the client side only mode.

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Arturo Zambrano
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: