bus-factor / ares Goto Github PK

As a user I want to allow strings to be null but not blank if provided.

Acceptance Criteria:

• The value is not required.
• If the value is set blankable, NULL and "" are valid values
• If the value is set not blankable, NULL is a valid value, but "" is not

As a user I want to make required fields nullable.

Acceptance Criteria:
If a field is required by validation schema, adding the validation rule nullable makes null a valid field value. By default values are not nullable.

Downgrade PHPUnit to v5.7

If undefined/unknown validation rule IDs occur in the validation schema, there's no proper error handling in place.

The error handling could either be done during schema sanitization (fail fast) or during validation.

As a user I want to validate integer values.

Acceptance Criteria:
Validation fails for all non-integer values.

As a user I want to validate a lists of similar data.

Acceptance Criteria:
A list of similar data is indicated by the additional data type list. This type also requires the user to define the input structure through a specific schema.
All list items in the input data are then validated against that schema and errors are added to the error list in case of validation errors.

As a user I want a concise documentation of the validator features.

Acceptance Criteria:
There exists a documentation about the basic usage of the validator and an detailed reference for all validator options including examples.

As a user I want to allow NULL values by default regardless of the validated type.

This behaviour is configurable using the "required" option in combination with the "type" option.

Acceptance Criteria:
required=false (default) --> validation of NULL values succeeds.
required=true --> validation of NULL values fails.

Make 'type' option mandatory.

Acceptance Criteria:
If the validation schema is missing the 'type' option an Exception is thrown.

As a user I want to validate by enum values like this:

$schema = [ 'type' => 'string', 'string' => [ 'in' => ['sandbox', 'production'], ], ];

'in' => sandbox, production
The value must be included in the given list of values.

'not_in' => 'admin'
The value must not be included in the given list of values.

Add a CHANGELOG.md to the project and add document features of v0.1.0.

http://kizu514.com/blog/setting-up-coveralls-io-with-travis-ci-and-phpunit/

As a user I want to control if fields are required by default.

Acceptance Criteria:
The user can provide the default behaviour of the validator regarding the required rule through the validation option allRequired. If allRequired is set true, all fields are required if not specified otherwise. If allRequired is set false, all fields are not required if not specified otherwise.

The validation schema is currently validated during the data validation. Depending on the data, errors in the validation schema might cause an Exception to be thrown, or not.

Therefore the validation schema should already be validation on validator construction.

As a user I want to exclude specific values of a field to be valid.

This essentially is the opposite of the 'allowed' rule --> 'forbidden' rule.

Acceptance Criteria:
If a particular value is configured as being invalid ('forbidden' => ['forbidden-value']), the validation should result in an error if the value equals any of the defined forbidden values.

Add an source code example for the validation option 'allowUnknown' to README.md

As a user I want to validate nested associative array structures.

Acceptance Criteria:
The validation schema supports the definition of validation rules for associative arrays.
The validation schema allows the definition of specific validation rules per field.
The solution supports nesting of associative arrays.

Idea:

// without custom message
$schema = [
    $ruleId => $ruleArgs,
];

// with custom message
$schema = [
    [
        $ruleId => $ruleArgs,
        'message' => 'My custom error message',
    ],
];

All rules have to be extended to support the additional options.

As a user I want to validate boolean values.

Acceptance Criteria:
Validation fails for other values than TRUE or FALSE.

As a user I want to validate float values.

Acceptance Criteria:
Validation fails for all values whose type is not float.

As a user I want to validate the exact length of strings.

Currently the exact length of strings can be validated using the minlength and maxlength validation rules with the identical value.

It should be possible to validate the exact length of strings with using only one validation rule.

Refactor builtin validation rules into separate classes.

All implemented validation rules are currently implemented hard-coded, so there's no interface for adding new validator rules or making changes to the existing validation rules without making changes to the core validation logic.

Acceptance Criteria:
Each builtin validation rule resides in a separate class and all validation rules share a common interface. The common interface allows for extending the validation rule set with custom validations.

As a user I want to define a custom validation error message for the "required" rule.

Acceptance Criteria:
The required rule defines a default error message. The user may provide a custom error message through the schema definition.

As a user I want unknown fields in array structures to cause validation errors.

Acceptance Criteria:
When validating array structures that contain fields that are not defined within the validation schema, these fields should cause validation errors.

As a user I want to allow required string to be blank.

Acceptance Criteria:
String values aren't allowed to be blank by default. However, the default behaviour can be changed by the user, so that strings values are valid if they're required and allowed to be blank.

As a user I want to validate integer values.

Acceptance Criteria:
Validation succeeds for string values.
Validation fails for all non-string values.

As a user I want to validate the maximum length of strings.

Acceptance Criteria:
When provided through the schema definition, the validation checks for maximum string length (applies to type=string only) and adds an error to the validation error list.

As a user I want required string value to contain other characters than whitespace.

Acceptance Criteria:
Validation fails if a required string contains only whitespace.

As a user I want to validate strings using regular expressions.

Acceptance Criteria:
When adding a regular expression based rule, only strings that match a given pattern are considered valid values.

As a user I want to control if fields are nullable by default.

Acceptance Criteria:
The user can provide the default behaviour of the validator regarding the nullable rule through the validation option allNullable. If allNullable is set true, all fields are nullable if not specified otherwise. If allNullable is set false, all fields are not nullable if not specified otherwise.

As a user I want to control if fields are blankable by default.

Acceptance Criteria:
The user can provide the default behaviour of the validator regarding the blankable rule through the validation option allBlankable. If allBlankable is set true, all fields are blankable if not specified otherwise. If allBlankable is set false, all fields are not blankable if not specified otherwise.

As a user I want to validation the minimum length of strings

Acceptance Criteria:
When provided through the validation schema, the validation checks for minimum string length (applies to type=string only) and adds an error to the validation error list.

As a user I want to validate date values.

• custom format (Y-m-d | Y.m.d | Y.m) validation
• date1 gt/lt/eq date2