Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    SpinnerItem validation not kicking in as expected

    We want to use a SpinnerItem that will only allow [-1000 .. 1000].

    We are not setting a default value because this form field is optional.

    We want the SpinnerItem to have a validation error whenever a value is not in the acceptable range.

    The problem we have is the following:
    if a user types (or pastes) a NON-numerical value, isc.SpinnerItem.updateValue() will silently ignore the invalid value and revert to the previous value.

    I attached a screenshot of our form to this post to illustrate why this behaviour is problematic for us:
    - There is a single field in the form.
    - If the user types "abc" in the spinner item's text box, he keeps the focus in the spinner item text field _AND_ he uses his mouse to click on the "Save" button; it will NOT be possible for the user to know the value he input has been ignored.

    We're quite reluctant to override updateValue() because this is likely to break in a future version.

    PS: We tried using "keyPressFilter" on the spinner item, but it won't work because we must support negative values and we had to use "[\-0-9]" as the regex. This ended up allowing the user to input "---1--" in the text field.

    What would be your proposal to fix the problem ?

    Thanks !

    SmartClient version: v9.0p_2013-12-03/Pro Deployment (built 2013-12-03)
    Attached Files

    #2
    As far as we can tell, your issue is that if the user clicks Save after entering an invalid value, the value vanishes and the dialog proceeds.

    If a value is required, setting a required validator would prevent progress and show an error. You could also have your click handler on the Save button just check for the value being empty and show a warning dialog via isc.warn().

    Either way, this seems like one of those issues that a tester reports but a real end user would never experience :) Especially with a keypressFilter in place, users do not tend to be mystified when a numeric field rejects "---1241--" - in fact they don't type such values in the first place.

    Comment


      #3
      Your idea about the required validator is a good one.

      Big picture: The screen shot that is in my 1st post only features one "row". We use this pattern in other part of our apps (screen to edit multiple records in batch, where each property has its own row). See attachment for a bigger screen where we use the same concept. As soon as the user types something in a field from the "Value" column, its associated "Action" field is initialized to a default action.

      It's the 1st time we integrate a spinner item in this kind of form.

      We already had the required validator in place but it was observing the "changed" event of the "Value" field. In the case of SpinnerItem, the "changed" event did NOT fire because the way SpinnerItem.updateValue() behaves and our "Value" field did NOT become required.

      In order to partially fix the current problem, I had the "Value" field implement keyPress(). So, as soon as the user has the focus in the SpinnerItem and he presses a keyboard key, the "Action" field will switch to a value that will make the field required. (One downside is even CTRL or SHIFT keys on their own will make the field required, but I can live with it right now).

      BUT, this brings me to my other problem:
      SpinnerItem's behavior for invalid values: silently reverting to previous valid value instead of clearing the field.

      New problematic scenario:
      - user inputs 67 in the SpinnerItem (this is a valid value)
      - my "Action" field is set to its default value (thanks to keyPress()); this makes the "Value" field required.
      - Focus is set out of the "Value" field; SpinnerItem saves 67 has a valid value.
      - Now, user puts the focus back in the "Value" field and types "abc"
      - User clicks on the "Save" button

      In this case, SpinnerItem will silently revert to 67 and submit this data to the back-end.

      The user will never be told that "abc" is invalid and he has no way to know that "abc" has been refused and SpinnerItem reverted to its last previous value.

      How can I prevent that ?

      Is there a way to tell SpinnerItem to clear oldValue on invalid/new input ?

      Looking forward to the answer ! I'd really love to integrate SpinnerItem in my UI.

      Thanks !
      Attached Files

      Comment


        #4
        Well, again we would disagree with this premise:

        .. he has no way to know that "abc" has been refused and SpinnerItem reverted to its last previous value.
        The user knows "abc" is not a valid value because it is obviously not a number. It's unclear that this situation exists at all for a real end user unless we are talking about something like a cat walking across the keyboard.

        If you really, really care about this case, you can detect this situation via using getEnteredValue() on keyPress() and noticing that the entered value is going to be rejected as invalid. This would put you in a position to have your own isc.warn() dialog catch this obscure edge case. But we honestly feel that this is misplaced effort - this behavior is unlikely to confuse anyone.

        Comment

        Working...
        X