Download the PHP package grithin/php-conform without Composer

PHP Conform Input

Ordered filtering and validation with standard input logic.

About

Back around 2009, I wanted to build something that would resolve having to code the normal input logic in situations like

• if x field failed, don't check y field
• if x field failed one step of validation, don't validate it further
• if x field failed validation, stop validating all input and return with error

There are a lot of combinations of this input field dependent logic which I thought could be simplified in expression. So, I created this class, which uses logic flags.

Use

Smallest Example

Setting The Input

Using Default Conformers

There are three conformers that come auto-attached to a Conform instance: \Grithin\Conform\Filter, \Grithin\Conform\Validate, and \Grithin\Conform\GlobalFunction. These are represented in rules by the prefixes f, v, and g.

To filter an input to an int, you can use f.int, but to validate the input is an int, you would use v.int. Filter and validate can be used in conjuction because the value passed to a proceeding rule is the output from the preceeding rule. For instance, we can filter to digits, and then check if the result is a valid int

g is used to reference a global function.

(The $Conform parameter will not be passed to the global function)

Adding Conformers

Use the conformer_add function.

The pathed callable must be callable at the path provided by the rule (according to lodash style pathing for _.get)

The callable receives the $Conform instance as the final parameter.

You can add various types of conformers

Using Flags

Form validation logic mostly follows patterns.

For example, if the id input is an int, check it in the database:

The ! says, ensure id input exists as an int before proceeding to the following rules on the field. In this way, we don't attempt to check the database with input that might be some arbitrary string.

What if we had multiple fields that relied on resolving a user id? You can exit out of validation entirely:

Here, the !! says, if id is not an int, exit with fail and parse no more fields. And if db.check fails, also exit with fail.

Sometimes there are optional fields that we still want to filter if they are present. To do this, you can combine two prefixes.

This says, if the field is not filled, stop applying the rule, but don't show as an error. This way, if the user left the field empty, there will be no email validation and no error, but if the user had filled out the email input, there will be email validation. (The order of ! and ? doesn't matter.)

Special Cases

There are prefixes for some rarer cases.

What if we wanted to collect multiple validation errors for a field, but then not process some ending rules b/c of the errors?

If the email field were not filled, this field rule set would result in an error for not being filled and an error for not validating as an email. The & prefix indicates, if there were any errors in the previous part of the rule chain, stop execution of rules for the field.

This can similarly be done for the entire form. What if we wanted to collect errors across multiple fields, but wanted the presence of those errors to prevent some ending rule exectuion?

Here, by use of the &&, if there were any errors in any of the previous chain or previous fields, the proceeding rule will not execute.

Finally, some times the reverse of a rule is desired. For instance, what if I wanted an email that was unique in the database but I just has a email_exists conformer function?

Here, the ~ is like a "not", and indicates a lack of error indicates an error.

Rule Format And Parameters

Parameters may be passed to a conformer in addition to the value of the input.

Here we see the | separates the parameters from the function path, and the ; separates the parameters from themselves. This form is the short form. Sometimes the use of ! or ; can be problematic, so there are long forms

Note, with the array separated callable, the function itself can be a callable instead of a path.

Retrieving Partial Output

Although get returns false if there were any errors, the Conform output for the fields that did not have errors is available with $Conform->output

Using The Errors

Errors are available from Conform and in the form of \Grithin\Conform\Error

The error objects can be used as arrays. There are three properties

• type
• message
• fields

It is left up to the implementor to change the message of the built in validation errors.

You can select the field or fields you want the errors for

Making Validation

Within a conformer, you can signal an error

A few things to note here

• the $Conform instance is passed in as the last parameter to the conformer function
• you can still return the value, even when there is an error, so that further validation can be done

By default, the error type will be whatever the path to the validator function was. But, you set your own type, and you can even specify the fields if the error is linked to multiple.

The current field is added into the fields array.

Context Data

Sometimes it is useful to know context data within a conform function. To access context data, you can use the $Conform instance that is passed in as the last parameter to conformer functions.

The context data that is useful:

• ->field the current field that is being conformed
• ->output the current output of the conform process (ie, fields that have been conformed)
• ->input the current input

Let's use a conformer that relies on the output of a previous field (field must come prior), and the input of another field

Validate And Filter Alone

You can use Validate and Filter pseudo statically, b/c they are traited with SingletonDefault.

Rule Item Prefixes

The prefix can be some combination of the following

• "!" to break on error with no more rules for that field should be applied
• "!!" to break on error with no more rules for any field should be applied
• "?" to indicate the validation is optional, and not to throw an error (useful when combined with '!' => '?!v.filled,email')
• "~" to indicate if the validation does not fail, then there was an error. Note, the original value (passed in to the function) will be pushed forward
• "&" to indicate code should break if there were any previous errors on that field
• "&&" to indicate code should break if there were any previous errors on any field in the validate run