We currently have a multiple approaches on when the validations should be shown on our table forms (Requisition View, Proof of Delivery View, Shipment View, Adjustment, Issue and Receiver screens). All validation are fired with a slight delay due to the debounce setting we're using. This was done to improve the performance.
Current approaches
...
1. Forms
Errors shows up only after the form is submitted. After the form has been submitted, but failed to do so because of errors, the errors for all inputs will be show. After that, validations will be fired every time the input is changed and error will be update (or cleared if the problem with the input has been fixed).
...
Example: Requisition Search page
2. Tables without form around them
The errors are show right after the input is changed or if it is focused out. Submitting the form causes all error to show up.
Level of effort to make standard: Medium (since we still would like these tables to be wrapped in forms - these are form after all - we would have to update a couple of directives to change the input behavior inside table - they errors should be shown immediately instead of waiting for submit)
| View file | ||||
|---|---|---|---|---|
|
Example: Product Grid, Adjustment, Issue, Receive screens
3. Tables with form around them
The errors won't be shown unless the row is left (focused out) or the form is submitted. After any of the actions has happened, the errors will be shown immediately. Leaving the row will cause all errors in that row to show up (even if the input wasn't touched). If the form also consist of inputs outside the table, their behavior will be the same as the one described in "Forms" approach.
...
Example: Proof of Delivery View, Shipment View
Tables without form around them
The errors are show right after the input is changed or if it is focused out. Submitting the form causes all error to show up.
Level of effort to make standard: Medium (since we still would like these tables to be wrapped in forms - these are form after all - we would have to update a couple of directives to change the input behavior inside table - they errors should be shown immediately instead of waiting for submit)
| View file | ||||
|---|---|---|---|---|
|
Example: Product Grid, Adjustment, Issue, Receive screens
4. Tables with form around them (with highlighting headers)
Works the same as "Forms with table inside", but also highlights the column header.
...
Example: Batch Approval screen
Recap
| # | Option | Level of Effort | User Benefit | Performance Impact | Screens which would change if this option is selected |
|---|---|---|---|---|---|
| 1 | Mimic what the other forms do. | Small | Consistency across the whole system | None |
|
| 2 | Make errors appear after the fields has been touched. | Medium | Instant error feedback |
| |
| 3 | Make errors appear after we leave (focus on something outside) the table row. | Large | When fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row) |
But, this approach will also require changing how pagination shows the page errors, it now is inconsistent with this approach and might require noticeable amount of work to make it happen | |
| 4 | Same as 3, but also highlight the table header. | Large | When fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row) |
|
Programming approaches
Currently we have a couple of different approaches on how to deal with validations from the coding side.
...