Tapestry 5
  1. Tapestry 5
  2. TAP5-987

In some cases you can invoke Form.recordError() and the Form will still fire a success (not a failure) event

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 5.2.0, 5.2
    • Fix Version/s: 5.2.0
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      The changes introduced into r898476 to address TAP5-979 has introduced the new ValidationTrackerWrapper.
      This seems to cause a regression in the way form validation is processed.

      The old (and wanted) way is to have onValidate to check for form-wide validations and store into the form (form.recordErorr) any found violation. Then if there are violations (errors recorded) the form fire the onFailure events otherwise go to onSuccess.

      With this changes the event path goes always from validate to success events, the failure event is never fired.

      The only possible workaround is to have the onFailure event handler method to return an object (typically this) and never be of type void.

        Activity

        Hide
        Howard M. Lewis Ship added a comment -

        There's a code path wherein invoking Form.recordError() (from inside a validate method) would record the error into a new instance of ValidationTrackerImpl, and the existing instance (used to check to see whether to invoke success or failure event) would not be aware of the recorded errors.

        Show
        Howard M. Lewis Ship added a comment - There's a code path wherein invoking Form.recordError() (from inside a validate method) would record the error into a new instance of ValidationTrackerImpl, and the existing instance (used to check to see whether to invoke success or failure event) would not be aware of the recorded errors.
        Hide
        Massimo Lusetti added a comment -

        I think this issue got to have an higher priority...

        Show
        Massimo Lusetti added a comment - I think this issue got to have an higher priority...

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Massimo Lusetti
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development