Form implements InputFilterProviderInterface - validators fix

[michalbundyra]

When Form implements InputFilterProviderInterface and validators for an element are defined in method getInputFilterSpecification, only these validators should be added to the InputFilter of the Form for the element.
The same behavior should be for Fieldsets and it works fine. Basically, validators defined in getInputFilterSpecification should override default validators of the Element.

[megapixar]

Does this fix mean, that I have to copy all filters from method getInputSpecification of elements like (Email, Number) or my custom element and paste it to getInputFilterSpecification just to set field 'required' => false ???
Does it make sense?

[michalbundyra]

@akrabat Could you have a look on it, please?

[michalbundyra]

@froschdesign @akrabat rebased

[akrabat]

Is this a BC break?

[akrabat]

i.e. if I add an email element and specify an additional validator that the length must be greater than 5, does this PR mean that the EmailAddress validator is no longer added?

[michalbundyra]

@akrabat I've created an example here: https://gist.github.com/webimpress/e08e5a8928cbc3fec249fdc723705652

So, without my fix we have got:

NUMBER OF VALIDATORS:
field   form    fieldset
email   2       1
custom  2       1

and with my fix we have:

NUMBER OF VALIDATORS:
field   form    fieldset
email   1       1
custom  1       1

Basically there is something wrong. I've decided to do this way, so override default validators. In my application always I'm using fieldset and always when I get field from fieldset (from a form) validators specified in getInputFilterSpecification are only used.

Please note, I haven't changed any tests, so I haven't break (tested) functionality. IMHO if you implement form with InputFilterProviderInterface then you want specify input filter rules in the form, so only these should be used.

[weierophinney]

This is a BC break, as it's a break in expectations. As an example, the comments in #78 indicate that developers are expecting that InputProvider elements are merged with the related input from an InputFilterProvider fieldset. This allows them to alter the input (e.g., change the required flag, add additional validators and filters) without needing to provide a full specification for the element.

That said, I can also see how this would be an area rife for problems, and we should likely revisit for a v3 release.

[weierophinney]

This repository has been moved to laminas/laminas-form. If you feel that this patch is still relevant, please re-open against that repository, and reference this issue. To re-open, we suggest the following workflow:

• Squash all commits in your branch (git rebase -i origin/{branch})
• Make a note of all changed files (`git diff --name-only origin/{branch}...HEAD
• Run the laminas/laminas-migration tool on the code.
• Clone laminas/laminas-form to another directory.
• Copy the files from the second bullet point to the clone of laminas/laminas-form.
• In your clone of laminas/laminas-form, commit the files, push to your fork, and open the new PR.
  We will be providing tooling via laminas/laminas-migration soon to help automate the process.

[michalbundyra]

This repository has been closed and moved to laminas/laminas-form; a new issue has been opened at laminas/laminas-form#44.