Details

    • Type: Task Task
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 4.1.1
    • Fix Version/s: 4.1.1
    • Component/s: None
    • Labels:
      None

      Description

      The validation error messages have changed between T4.0.x and 4.1.x. The change was made in an attempt to provide a better hint to the user about what made their input invalid. There is some dispute on the user list as to whether the changes made overly complicate things or actually make things easier for the user.

      Moreover, there's dispute about whether changing the messages is considered a backwards-incompatible change. Developers may have come to rely on these messages and not expect the change. In my own case, it broke integration tests I had that checked for the presence of a particular error message.

      There's also dispute over whether the detailed messages are more appropriate for developers or for end users. If this is all the issue comes down to, adding a "debug" property might be a nice compromise for switching between the two (although, maintaining two sets of messages may be cumbersome).

      At the very least, the changes should be reviewed and some general consensus reached about how to move forward.

        Activity

        Hide
        Jesse Kuhnert added a comment -

        Fixed the numeric/number based strings.

        I noticed that dates get this "format is " string but can't remember if that is something I added or not. Either way I think it actually does make sense for dates so will probably need some stronger convincing if that isn't what others think.

        Show
        Jesse Kuhnert added a comment - Fixed the numeric/number based strings. I noticed that dates get this "format is " string but can't remember if that is something I added or not. Either way I think it actually does make sense for dates so will probably need some stronger convincing if that isn't what others think.
        Hide
        Sam Gendler added a comment -

        I don't know enough about hivemind, but if it is possible to use hivemind to allow a user to override the properties en-masse, then it would definitely be useful to many a developer to have validation messages that do contain developer-specific info like format patterns or even the entire string that was passed to the validators binding of the component. I'd love to be able to run with developer messages right up through most of the QA cycle, so that when errors get reported, I've got as much info as possible, just not at the expense of having to manually override all the built-in messages.

        Show
        Sam Gendler added a comment - I don't know enough about hivemind, but if it is possible to use hivemind to allow a user to override the properties en-masse, then it would definitely be useful to many a developer to have validation messages that do contain developer-specific info like format patterns or even the entire string that was passed to the validators binding of the component. I'd love to be able to run with developer messages right up through most of the QA cycle, so that when errors get reported, I've got as much info as possible, just not at the expense of having to manually override all the built-in messages.
        Hide
        Jesse Kuhnert added a comment -

        Yeah, it will be changed back to the old messages - just need a little more time for my next wave of tap dev to do it.

        Show
        Jesse Kuhnert added a comment - Yeah, it will be changed back to the old messages - just need a little more time for my next wave of tap dev to do it.

          People

          • Assignee:
            Jesse Kuhnert
            Reporter:
            Kevin Menard
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development