Download the PHP package popphp/pop-validator without Composer

pop-validator

• Overview
• Install
• Quickstart
  • Match against multiple patterns
  • Validate nested or related data
  • Discover available validators
• Validation Sets
  • Multiple Validators
  • Custom Messaging
  • Lazy-Loading vs Eager-Loading
  • Strictness
  • Conditions
  • Rules
  • Rule Messages
  • Referencing Fields
  • Referencing Nested Fields

Overview

pop-validator is a component for validating values and returning the appropriate result messaging. The component comes with a set of built-in evaluation objects and also the ability to extend the component and build your own.

pop-validator is a component of the Pop PHP Framework.

Top

Install

Install pop-validator using Composer.

composer require popphp/pop-validator

Or, require it in your composer.json file

"require": {
    "popphp/pop-validator" : "^5.0.0"
}

Top

Quickstart

Here's a list of the available built-in validators, all under the namespace Pop\Validator\:

Check an email value

Validate against a specific value

Set a custom message

Alternatively:

Match against multiple patterns

RegEx also accepts an array of patterns as its value. By default, every pattern must match. Pass a third constructor argument to require only a minimum number of them to match instead:

Validate nested or related data

The Has* family of validators (HasOne, HasOnlyOne, HasCountEqual, HasOneThatEquals, HasOneThatContains, their DateTime variants, and others) work differently from the rest of the built-in validators. Instead of checking a single value, they're handed the entire input array and check for the presence, count, or value of a field inside it - including fields nested in sub-arrays, addressed with dot notation.

Dot notation reaches into nested arrays:

Discover available validators

ValidatorSet::getAvailableValidators() returns every built-in validator class name mapped to its snake_case rule name, which is useful for building dynamic forms or admin UIs:

Top

Validation Sets

Validation sets are a way to group validators together to evaluate all of them at one time. With that, a level of strictness can be set to enforce whether or not all the validations have to pass or just some of them.

Multiple Validators

Custom Messaging

Lazy-Loading vs Eager-Loading

If the validators are added to the set validator using the add* methods will store the validator configuration and not create the validator objects until the validator set is evaluated (lazy-loading.) Using the load* methods, actual validator objects will be stored in the instance of the validator set object (eager-loading.)

Strictness

The strictness of the validator set can be set as needed. If set to STRICT_NONE then only one validator in the set would have to pass in order for the whole set to pass. The same applies for conditions as well:

Available strict constants are:

• STRICT_NONE
• STRICT_VALIDATIONS_ONLY
• STRICT_CONDITIONS_ONLY
• STRICT_BOTH (default)

Top

Conditions

Conditions can be added to a validation set that would need to pass in order for the validations to evaluate. Conditions are validators themselves. And the strictness level can be utilized as well to enforce whether or not all the conditions pass or just some of them.

Note: By default, conditions store their validation configuration via lazy-loading and do not create the validator object until the condition is evaluated.

In the above example, if the value of client_id is changed to 2, the validators will not be evaluated, as the required conditions would not be satisfied.

Top

Rules

Rules provide a shorthand way to wire up validations and conditions within the validation set. Rules are colon-separated strings compromised of a field, a validator and optional value and message values. The validator should be a snake_case format of the class string, e.g. HasOne class should be written as has_one.

Below is the same example from above, but using rules instead:

Conditions can be added using rules as well. Here is the example from above using rules instead:

Rule Messages

Custom messaging can be passed via the rule format as well, in the 4th position:

Referencing Fields

When writing rules, fields passed into the input data at the time of evaluating the data can be accessed by using brackets:

Referencing Nested Fields

The bracket syntax above is for referencing another field's value inside a rule string. That's different from pointing a validator at a nested field to check, which is done by calling setField() directly on a validator instance with a key[field] bracket pattern: it tells the validator to check $input[key][field] instead of the top-level field it would normally be handed.

Top