Explore UI improvements around Category and Handicap terminology

[carltonwhitehead]

During early feedback, several people seized on use of terms Category and Handicap, expressing confusion about their meaning, especially how laymen might be interpret them. There seems to be room to simplify here.

These are used in several places currently:

• Run Event Table View
  • Category column
  • Handicap column
• Add Next Run Form
  • Numbers field hint text
  • Autocomplete order preference
• Change Driver Form
  • Numbers field hint text

Additionally, the autocomplete suggestions provider used for the various Numbers fields relies on the lookup tokens being entered in a defined order. Explore removing this limitation.

Explore combining the Category, Handicap, and Number columns of the Run Event Table View into a single Numbers column, mimicking the Numbers field of the Add Next Run Form and Change Driver Form. Expect to lose the ability to perform inline driver changes using the table view's editing feature -- users will rely on the Change Driver Form dialog instead.

[carltonwhitehead]

Work for this issue is happening in branch 8-no-category-handicap.

Some notes about the implementation plan:

Numbers field

Validation

Validator to split value on spaces, each entry referred to as tokens

• Valid when there are two tokens and [0] is numeric
• Valid when there are three tokens and [0] is numeric
• Valid when the registration list has a selection (whether user-directed or auto-selected based on edit distance)

Suggestions

Live suggestions will use an indeterminate token lookup against the full text of Registration Number, Category, and Handicap. For example, consider the below registration table:

• STR 8
• NOV SM 8
• NOV STR 18
• NOV STR 1
• NOV STR 8

When the Numbers field contains:

• "ST" or "STR" -- it should suggest "STR 8", "NOV STR 18", "NOV STR 1", "NOV STR 8"
• "NOV" -- it should suggest "NOV SM 8", "NOV STR 18", "NOV STR 1", and "NOV STR 8"
• "8" -- it should suggest "STR 8", "NOV STR 18", "NOV STR 8"

Registration assignment

It should automatically resolve a full Registration record corresponding to real registration data based on a single match from the full text lookup, or the nearest match if its Levenshtein edit distance is less than all others. In case that's not feasible, it should allow arbitrary entry from valid 2 or 3 token Numbers field entry.