Download the PHP package longdinhh/validation without Composer

Validation

This is a re-write of rakit/validation, a standalone validator like Laravel Validation. In keeping with rakit/validation, this library does not have any other dependencies for usage.

Please note that the internal API is substantially different to rakit/validation.

Jump to rules

Requirements

• PHP 7.2+
• ext/mb-string

Installation

Install using composer, or checkout / pull the files from github.com.

• composer require longdinhh/validation

Usage

There are two ways for validating data with this library: using make to make a validation object, then validate it using validate; or use validate.

For example:

Using make:

or via validate:

You are strongly advised to use a Dependency Injection container and store the Factory as a singleton instead of creating new instances. This will reduce the penalty for creating validation instances and allow custom rules to be more easily managed.

Attribute Aliases

Unlike rakit/validation, attribute names are not transformed in any way; instead if you wish to name your attributes, aliases must be used.

Aliases can be defined in several ways: on the rule itself, or by adding the alias to the validation. Note that aliases should be set before calling validate.

Validation Messages

Validation messages are defined in Resources/i18n/en.php. Any message can be replaced with a custom string, or translated to another language. The English strings are always loaded during Factory instantiation.

Depending on the failure type, various variables will be available to use, however the following are always available for all messages:

• :attribute: the attribute under validation, alias will be used if set,
• :value: the value of the attribute under validation, converted to string with arrays and objects as JSON strings.

Custom Messages for Validator

All messages are stored in a MessageBag on the Factory instance. Additional languages can be added to this message bag, or customised on the specific validation instance. Additionally, the default language can be set on the message bag on the Factory, or a specific language set on the validation instance.

To add a new set of messages:

Or override the default English strings:

Or set the default language:

Custom Message for Specific Attribute Rule

Sometimes you may want to set custom messages for specific attribute rules to make them more explicit or to add other information. This is done by adding a message key for the attribute with a : and the rule name.

For example:

Custom Messages for Rules

Some rules have several possible validation messages. These are all named as rule.<name>.<check>. To change the message, override or add the specific message.

For example uploaded_file can have failures for the file, min/max size and type. These are bound to:

• rule.uploaded_file
• rule.uploaded_file.min_size
• rule.uploaded_file.max_size
• rule.uploaded_file.type

To change any of the sub-messages, add/override that message key on the message bag.

For example:

Unlike rakit, it is not possible to set custom messages in the Rule instances directly. Any message must be set in the message bag.

Complex Translation Needs

The system for translations in this library is rather basic. If you have complex needs, or wish to handle countables etc. Then all error messages are stored as ErrorMessage instances containing the message key and the variables for that message.

Instead of using the ErrorBag to display messages, you can use the underlying array (or a DataBag instance) and then pass the message keys to your translation system along with the variables.

Note that errors are a nested set by attribute and rule name.

Working with Error Messages

Error messages are collected in an ErrorBag instance that you can access via errors() on the validation instance.

Now you can use the following methods to retrieve the messages messages:

all(string $format = ':message')

Get all messages as a flattened array:

firstOfAll(string $format = ':message', bool $dotNotation = false)

Get only the first message from all existing keys:

Argument $dotNotation is for array validation. If it is false it will return the original array structure, if it is true it will return a flattened array with dot notation keys.

For example:

first(string $key)

Get the first message for the given key. It will return string if key has any error message, or null if key has no errors.

For example:

toArray()

Get the raw underlying associative array of ErrorMessage objects.

For example:

toDataBag()

Get the raw underlying associative array of ErrorMessage objects as a DataBag instance.

For example:

count()

Get the number of error messages.

has(string $key)

Check if the given key has an error. It returns true if a key has an error, and false otherwise.

Validated, Valid, and Invalid Data

After validation, the data results are held in each validation instance. For example:

Now you can get the validated data, only the valid data, or only the invalid data:

Available Rules

Click to show details.

Register/Override Rules

By default, all built-in rules are registered automatically to the Factory instance. Some of these are required internally (e.g. required and callback); however you can override or add any number of new rules to the factory to use for your validations.

This is done by accessing the addRule() method on the Factory and adding a new rule instance.

For example, you want to create the unique validator that will check field availability in a database.

First, lets create UniqueRule class:

Now to register this rule it needs adding to the Factory instance:

Now you can use it like this:

In the UniqueRule above, the property $message is used for the invalid message. The property $fillableParams defines the order and names of the arguments for the rule. By default, fillParameters will fill parameters listed in $fillableParams from the string rules. For example unique:users,email,[email protected] in example above, will set:

If you want your custom rule to accept parameter lists like in,not_in, or uploaded_file rules, you need to override the fillParameters(array $params) method in your custom rule class.

Note that the unique rule that we created above also can be used like this:

You can improve UniqueRule class above by adding some methods to set the params instead of using the string format:

Now configuring the rule becomes:

Implicit Rule

An implicit rule is a rule that if it's invalid, then next rules will be ignored. For example if the attribute didn't pass required* rules, the next rules will be invalid. To prevent unnecessary validation and error messages, we make required* rules to be implicit.

To make your custom rule implicit, you can make $implicit property value to be true. For example:

Modify Value

In some cases, you may want your custom rule to be able to modify the attribute value like the default/defaults rule. In the current and next rule checks, your modified value will be used.

To do this, you should implement Coccoc\Validation\Rules\Contracts\ModifyValue and create the method modifyValue($value) on your custom rule class.

For example:

Before Validation Hook

You may want to do some preparation before running the validation. For example the uploaded_file rule will resolve the attribute value that comes from $_FILES (undesirable) array structure to be a well-organized array.

To do this, you should implement Coccoc\Validation\Rules\Contracts\BeforeValidate and create the method beforeValidate() on your custom rule class.

For example:

Tests

PHPUnit 9+ is used for testing. Run tests via vendor/bin/phpunit.