Inline form field validation

[bennothommo]

This PR is a resubmission of #4034 with a core branch.

This is a WIP to implement inline form field validation for forms built with the Form widget.

One of the shortcomings of validation in October currently is that the form is validated on submission, and only one error message is shown via a flash message. While this is fine for smaller forms, when larger forms are produced, and the possibility of multiple fields having issues increases, it could cause frustration getting messages one at a time.

This pull request aims to provide immediate feedback on errors with form field contents by:

• Adding a validation call when a field has lost focus or has changed.
• Validating the linked model for the current form and retrieving any errors for the changed input in the context of the entire form contents. (ie. if a field is invalid due to the contents of another field, this too needs to be detected)
• Showing the validation error in a friendly way to the user (perhaps as a message underneath the field, or as an icon next to the label and using a tooltip message to display the error)

At the moment, the scope is to only handle simple form fields, such as text inputs and textareas, select dropdowns, radio options, and checkboxes, but could potentially extend to more advanced widgets if they can be easily validated in the context of a model.

Tasks:

• Add onValidate event for fields in Widget
• Add JS bindings for all simple types of form fields
  • Text-field based fields (text, textarea, number and password)
  • Dropdowns and balloon selectors
  • Checkboxes, switches and checkbox lists
  • Radio lists
• Add error messages to form
• Prevent form submission if any fields have errors
• Add boolean to form_config.yaml to enable/disable validation
• Add hooks to allow plugins to extend field validation
• Add unit tests
• Add example to test plugin

[ghost]

This is a very interesting PR, will this be automatic or will we need to add anything to the YAML files?

Also will there be any option to add custom regex and/or to create custom tool tips in any of the form fields, to fine tune things from default messages.

[ghost]

I wonder if this would be useful to you? I have been adding this to textarea and text fields in October's backend, see gif screenshot:

Helps to work out the character limits in the fields. I think this is related to this pr?

[LukeTowers]

@ayumihamsaki that would be a separate feature. See the discussion in the previous PR for more information on how this works.

[bennothommo]

@ayumihamsaki There will be a flag in the YAML file for either the form config or the fields config called inlineValidation. The intention is that this flag could be used to enable or disable inline validation at a field level or for an entire form.

It uses the validation and messages that are already defined for normal model validation via the Validation trait.

[ghost]

1. LukeTowers, thanks will have a read through the previous pr, I wasn't ware of it.

2. bennothommo, cool will follow this pr and be happy to beta test it later on ... I think this will enhance pretty much every plugin out there.

[w20k]

@bennothommo I have an idea, need your opinion, about how sane it is :)

Improvement: To bake all validation rules and store them on the front-end.
Get all rules from models, pass them to the october.form.js (on load) and run validation via JS. Post form when isValid === true. So, that the backend will only validate the single formPost request.

Minor Tab UI improvement: Add icon for tabs where validation failed.

[bennothommo]

@w20k Definitely on board with the Tab UI idea. I think the front-end baked validation might be good as a complement to the inline validation, however, I wouldn't trust the validation being done fully on the front-end as that leaves it open to be circumvented (ie. people using the Developer Tools to remove the validation and sending through incorrect data). It still definitely needs to be checked server-side.

[w20k]

@bennothommo yeah, post validation should be done also on serve, that's no doubt!
The idea is to simplify the front-end validation for huge forms with more than 5-10+ components, or multiple tabs. Right now it will send a request for field interaction (change/blurred). Would even call it pre-form validation on front-end, and then on $form[0].submit make a back-end validation :) To speed up things.

Thanks, @bennothommo for your input! ;)

[bennothommo]

@w20k One of the main reasons I was setting it up to validate completely server side was due to some of the complex validations that can be done through the Validation trait as well as allowing plugins to hook into an event that will be provided. Those things could not really be emulated completely in front-end.

[w20k]

Shoot me with an example @bennothommo, if you have one in mind. Maybe there is an option to implement it on the front-end 😄 If it's too complex will leave as it is, still an awesome addition!

[bennothommo]

@w20k One that immediately springs to mind is a "unique" check, for example for slugs.

[github-actions]

This pull request will be closed and archived in 3 days, as there has been no activity in the last 60 days.
If this is still being worked on, please respond and we will re-open this pull request.
If this pull request is critical to your business, consider joining the Premium Support Program where a Service Level Agreement is offered.

[daftspunk]

Not really a shortcoming, quite a common pattern to save on double handling in the code, which is what this code introduces. Users don't really care about immediate feedback and a delay upon submission is seasoned UX