[WIP]Move FormField's custom option validation to field construction

[ElijahAhianyo]

fixes #294

[codecov]

Codecov Report

Attention: Patch coverage is 97.14286% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
cot/src/form/fields.rs	97.14%	1 Missing ⚠️

Flag	Coverage Δ
rust	85.11% <97.14%> (-0.03%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
cot/src/form/fields.rs	78.45% <97.14%> (-0.12%)	⬇️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[m4tx]

I think adding a new trait for this isn't ideal. The problem is that it has to be implemented for each Options struct, and it's not even very useful for the end users—note we only use it in a helper macro (not even a public one). This means that the documentation "The validation is performed when FormField::with_options is called" is not really true, as you can always provide your own with_options implementation.

I can see the following alternatives, in the order of my preference:

1. Changing the macro so that it can optionally call validate() or some similar method (not defined in any trait) on the options struct, if needed (the macro call would change to something like impl_form_field!(StringField, StringFieldOptions, "a string", with_validate) for the structs that need to be validated, fro instance.
2. Making the trait private (there is no promise for the users, so there's no problem, but we still have to add impl for every options struct)
3. Making the helper macro public (but there still is no obligation to use the macro, so the trait promise is still broken)

What do you think?

[seqre]

I like option 2 the most and it might not require as much work in the end, we could incorporate the default implementation into the impl_form_field! macro, but leave an escape hatch for custom validation.

Go from this:

macro_rules! impl_form_field {
    ($field_type_name:ident, $field_options_type_name:ident, $purpose:literal $(, $generic_param:ident $(: $generic_param_bound:ident $(+ $generic_param_bound_more:ident)*)?)?) => {
        ...original impl...
}

To this:

macro_rules! impl_form_field {
    ($field_type_name:ident, $field_options_type_name:ident, $purpose:literal $(, $generic_param:ident $(: $generic_param_bound:ident $(+ $generic_param_bound_more:ident)*)?)?) => {
        impl_form_field!(...arguments from above..., custom-validation)

        impl ValidateOptions for $field_options_type_name {}
}
    ($field_type_name:ident, $field_options_type_name:ident, $purpose:literal $(, $generic_param:ident $(: $generic_param_bound:ident $(+ $generic_param_bound_more:ident)*)?)?, custom-validation) => {
        ...original impl...
}

[m4tx]

@seqre how do you specify custom validation code with your approach? ah, I see the custom-validation part. In this case, it's okay (although I don't have a strong preference of 1 or 2).