Highlighting fields that fail validation in config creator GUI

[HEdingfield]

This would probably require a fairly significant rework of the validation functions, but might be nice to implement using a similar technique as this: https://youtu.be/cwJK_WpseKQ?t=5m43s

[gngilbert]

We definitely need to provide clear info to users as to the cause of validation failure.

[chughes297]

@gngilbert @freedomcounts This feels like a certification requirement but am concerned about applying that label if it's extremely time-consuming and ultimately a quality of life fix. Could this be a de minimis change, too?

[HEdingfield]

I've got a local proof-of-concept working for this right now on one field, and wanted to sanity check the design before doing it for everything because it'll be a big change:

1. Change ContestConfig.validate to return a Set of error codes (enum values) that occurred during validation instead of a boolean.
2. Change GuiConfigController to apply an error CSS style to the element(s) in question for each type of validation error that's returned when the user clicks the "add" button in the Candidate or CVR tabs, or when they choose "Validate" or "Tabulate" from the menu (this would also need to include logic on when to remove these styles).

First pass might be to just trigger the red highlighting when the "Add" button is clicked for candidates or CVRs. Would there be a value in at least launching this before the others below?

Second pass could catch all the other rules when the user chooses "Validate" or "Tabulate" from the menu, though it could be tricky feeding back the list of validation errors from the service that runs here: https://github.com/BrightSpots/rcv/blob/b33722c54e1ed33adc9a0ea11d3ca4782a8bc66c/src/main/java/network/brightspots/rcv/GuiConfigController.java#L1264

Some ideas on how to do that here and here.

Third pass would attempt to highlight individual cells in the Candidate or CVR tables, instead of the entire table, if they failed validation (which I believe could only happen if they were created outside of the GUI).

How does this sound? And is there a value in getting the first pass done first and launched for v1.3 even if I'm not able to get to the other passes in time?

[tarheel]

Sounds generally reasonable to me.

Third pass would attempt to highlight individual cells in the Candidate or CVR tables

I don't know that this part is worth the trouble.

And is there a value in getting the first pass done first and launched for v1.3 even if I'm not able to get to the other passes in time?

Eh, I wouldn't rush it. I'd say that we should include it once you've completed the first two passes. But I also wouldn't say there's meaningful downside to including the first pass on its own in our next release.

[HEdingfield]

I don't know that this part is worth the trouble.

Nice to hear that, because it could be a pain. :)

@chughes297 @rrojas350 would either or both of you mind commenting as well?

[rrojas350]

I like how you've worked out each pass, but if something like the third pass is more trouble than it's worth, it's definitely not a deal breaker.

As for including the first pass in v1.3, I'm for it. This way we can try out the functionality and see if it's something we want to flesh out more down the road or ultimately not really worth the trouble overall.

[HEdingfield]

I've implemented the first pass mentioned in https://github.com/BrightSpots/rcv/issues/137#issuecomment-1214427620 via PR #618.

The second pass will require a comprehensive check on every possible ValidationError to catch every one that hasn't yet been accounted for in GuiConfigController. We should avoid calling highlightInputsFailingBasicCvrValidation (and its equivalent code for candidates inside buttonAddCandidateClicked) when the user selects "Validate" or "Tabulate" from the menu, as it only makes sense for the validation handled in the first pass to be triggered by clicking the "add" buttons (it should be fine to clear all the validation formatting as the first thing, though).

Another note for the second pass: any checkboxes that need validation highlighting should use the class check-box-error instead of just error.