Download the PHP package alexanevsky/input-manager-bundle without Composer

Input Manager

This library allows you to map incoming data (for example, from JSON) into an object, modify it, validate it, and map it to your model or Doctrine entity. This allows you to treat the data as an object and still prevent invalid property values for your model or Doctrine entity.

The library consists of three components:

• Deserializer
• Validator
• Mapper of input data to the model

Let's analyze each of them step by step.

Table of Contents

1. First Step
2. Deserializer
   • Basic Example
   • Type Conversion
   • Objects Deserializing
   • Nested Inputs Deserializing
   • Input Collection Deserializing
   • an Entity by Identifier Deserializing
   • an Array of Entities by Identifier Deserializing
   • Input Modifier
3. Validator
   • Constraints Validator
   • Extended Validator
   • Extended Validator Payload
4. Input to Object (Model) Mapper

First Step

Add InputManager to the constructor of controller or service:

Deserializer

Basic Example

Let's imagine that we have some model:

To map the data from the request to this model, we will use an intermediate object that implements InputInterface so that we can check and modify the incoming data if we need it:

We can describe properties as public. We can also make them private and use setters and getters:

You can use any approach you want. We will use public properties in this documentation.

Note: If a public property has a getter (or setter), it will take precedence, i.e. the value of the getter will be taken (passed to the setter) rather than taken from the property (rather than assigned to the property). You can see more about how getters and setters are used in the library alexanevsky/getter-setter-accessor.

So, the first step we need to do is deserialize our request to the Input object.

Or we can create an object during deserialization (either approach can be used):

Please note that the deserializer can work with keys in both camel and snake cakes.

As a result, our $input will be like this:

Type Conversion

The deserializer can convert simple data types.

Imagine that our Input expects the following data:

And we will pass data of a slightly wrong type:

As we can see, the deserializer coped with this task and converted the types to the required ones.

Objects Deserializing

Imagine that we have a model that takes some object as its property.

In our Input class, we must use it:

As a result, our Input will be successfully deserialized from this JSON:

Nested Inputs Deserializing

Your Input can accept a nested Input, which will also be deserialized and converted into the appropriate model object in the future.

Imagine that we have a model that accepts another model as its property.

These models will correspond to the following Input classes:

As a result, our ArticleInput will be successfully deserialized from this JSON:

Input Collection Deserializing

If our model has a property that does not contain one other model, but an array of models, we can create a collection input class that implements InputCollectionInterface (even easier - extends AbstractInputCollection), and define in it which Input we need to use:

As a result, our ArticleInput will be successfully deserialized from this JSON:

an Entity by Identifier Deserializing

Imagine that in the request data we only have the identifier of some entity, but we need to deserialize it into the entity itself:

Our entities look like this:

To get the Category object by the passed id, add the EntityFromId attribute to our Input class, specifying which class we expect as the first parameter:

As a result, our ArticleInput will be successfully deserialized from this JSON:

We can also do without the suffix:

If the identity property of our Category is different than id, we need to pass the name of the identity property as the second parameter to EntityFromId:

As a result, our ArticleInput will be successfully deserialized from this JSON:

We can also do without the suffix:

We can also specify with the third parameter EntityFromId what suffix we expect in the input data:

As a result, our ArticleInput will be successfully deserialized from this JSON:

We can also avoid the suffix, as in the two examples above.

If we don't want any suffix at all, we must pass false as the third parameter of EntityFromId:

an Array of Entities by Identifier Deserializing

The EntityFromId attribute described above can also be used for models.

A slight difference is that if the second parameter (suffix) is not specified, the deserializer will expect it with s at the end. That is, our ArticleInput will be successfully deserialized from this JSON:

We can also do without the suffix:

Input Modifier

We can implement our Input from InputModifiableInterface instead of InputInterface. This will allow us to add a modify() method that will be called immediately after deserialization. This will allow us to change some of our Input data.

So, given the following as request:

Our Input will be with the following data after derealization:

Validator

Constraints Validator

The easiest way to validate is to use Symfony Constraints.

Let's set the constraints attributes on our Input class:

After we have deserialized our Input, let's validate it:

As a result, we will get an associative array of errors, in which the key is the name of the property in which the error occurred, and the value is TranslatableMessage with the error message.

Extended Validator

We can create our own extended validator that will implements InputValidatorInterface (even easier - extends AbstractInputValidator). In it, we specify the validate() method, which will perform the necessary checks and return an associative array of errors, in which the key is the name of the property in which the error occurred, and the value is TranslatableMessage with the error message. If it returns an empty array, it means that the validation was successful.

To use this validator, specify its class name as the second parameter to the validation method:

Note that the extended validator will only be called if there were no errors defined by constraints.

We can choose another way: in our extended validator, create validation methods for each property by prepend validate to the property name in the method name. We will have to return TranslatableMessage if there is an error, or null if there is no error.

Extended Validator Payload

We can also pass some payload to our validator to use in validation. To do this, we will add a public property and add the SetFromPayload attribute to it, which will tell the validator that the value of the property should be received from the payload. We can also set the boolean requred parameter. If required is true and there is no data in the payload, we will have an exception. For example, we can pass to the validator the entity of our user for whom the current Input is being processed.

To pass the payload to the extended validator, pass it as the third parameter to the validator method:

Input to Object (Model) Mapper

Finally, having completed the deserialization and validation, we need to map the data from our Input to our Model. We will do this by simple method:

And all our deserialized valid data from Input will be set to the user by public properties and setters.

Good luck!