Skip to content
This repository was archived by the owner on Jan 30, 2020. It is now read-only.

[WIP] [RFC] Control flow descriptors #103

Closed
carnage opened this issue Apr 8, 2016 · 4 comments
Closed

[WIP] [RFC] Control flow descriptors #103

carnage opened this issue Apr 8, 2016 · 4 comments

Comments

@carnage
Copy link

carnage commented Apr 8, 2016

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.

@weierophinney
Copy link
Member

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.)

@Maks3w
Copy link
Member

Maks3w commented Apr 8, 2016

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.

@carnage
Copy link
Author

carnage commented Apr 11, 2016

"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

@carnage carnage closed this as completed Apr 11, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants