-
Notifications
You must be signed in to change notification settings - Fork 49
[WIP] [RFC] Control flow descriptors #103
Comments
FYI, @Maks3w has specced out some ideas previously, including a filter chain / visitor approach; some are in issues already posted, and some were in gists. (Hoping that pinging him will get him to post links.) |
There are mainly two options about a future architecture This one about how to redefine the input as a chain of filter/validator methods #87 Alternative you can propose in the Zend\Validator issue tracker the changes you have described. This component try to have zero knowledge about the validator itself, instead it expose the ValidatorChain object which is the responsible of perform to take the decissions you have described. |
"Alternative you can propose in the Zend\Validator issue tracker the changes you have described. This component try to have zero knowledge about the validator itself, instead it expose the ValidatorChain object which is the responsible of perform to take the decissions you have described." Considering it over the weekend; I think you are on the right track here. Though the scope of the changes probably means it would be better to create a new class as opposed to overloading the Validator Chain; I'll close this and reopen something on zend-validator when I've got some ideas together |
Allow empty and continue if empty are currently flags which allow a small amount of control over the flow of validation; unfortunately their implementation has given rise to a number of hard to fix issues. As a proposed solution, I suggest moving this functionality to validators and making it more generic.
A validator can return either true or false. We should give a developer a tool to allow them to decide what to do next depending on the return value. Possible options are:
Continue running further validators
Continue running further validators but mark the input as having failed validation
Stop running validators, mark the input as having failed validation
Stop running validators, mark the input as having passed validation
and possibly:
Run this alternative set of validators
This would replace the allow empty, continue if empty and break chain on failure options from the input class
TODO: spec this out; design interfaces and show use cases.
The text was updated successfully, but these errors were encountered: