Download the PHP package paysera/lib-normalization-bundle without Composer

Paysera Normalization Bundle

This bundle allows to de/normalize your business entities (plain PHP objects) without tightly coupling them with your normalization format. You would usually do this before converting normalized structure to JSON or after converting from it.

Why?

Symfony has Serializer component that has normalizers as a part of it. This component is created for similar reasons but with different approach.

Symfony component exposes your business entities by default, but allows sophisticated but challenging configuration options. It also writing custom normalization logic, but it usually resides inside your normalized classes (which probably are plain PHP objects).

Paysera Normalization library embraces simplicity by always writing a bit of code for getting full control of the situation – normalization logic is placed in related classes, which are usually registered from DIC. This allows to use other services, fetch data from database, call remote services if needed or make any other things in familiar PHP source code. You can easily rename any fields, use any custom naming, duplicate some data for backward compatibility or, well, just write any other code. No difficult configuration is needed for edge-cases, as you have full control over the situation.

Main features of this bundle:

• supports explicit type safety when denormalizing by integrating lib-object-wrapper;
• normalization type can be guessed by passed data;
• easily reuse other de/normalizers without direct dependencies;
• supports different normalization groups with fallback to default one;
• supports explicitly or implicitly included fields, allowing performance tuning in normalization process.

Installation

Configuration

Basic usage

Write de/normalizers for your business entities:

If you don't use auto-configuration (also keep in mind that it works only when you implement TypeAwareInterface), tag your services:

Use for de/normalization:

Advanced usage

Available tags

If service does not implement TypeAwareInterface interface, type attribute is required. You can provide it in any case to overwrite any value returned from getType method.

group attribute instructs to register de/normalizer to specific normalization group instead of default one. See usage on normalization groups below for more information.

You can use several (even same) tags on a service. For example:

Normalizing data

Normalization is a process of converting your business objects to "normalized" (plain) structures.

This can be done when returning them as response to REST requests, before sending to some MQ system, before storing to any relational or NoSQL database or in any other case where you need plain, manageable representation.

Normalization is initiated by using CoreNormalizer (paysera_normalization.core_normalizer service) normalize method which has the following interface:

If $type is not passed, code tries to find registered normalizer in this order:

• for scalar values, same value is returned;
• for arrays, it's values are mapped by recursively guessing their normalizer types;
• for objects, normalizers with the following types (in this order) are looked for:
  • fully qualified class name of the object;
  • all parent classes of the object;
  • all implemented interfaces of the object;
  • if object implements Traversable, it's treated same as an array;
• NormalizerNotFoundException is thrown if type is not resolved.

With NormalizationContext you can customize normalization group and included fields. Keep in mind that NormalizationContext needs the same CoreNormalizer instance when constructing it – it's passed down to concrete normalizer instances which needs easy way to recursively normalize internal structures.

Included fields

You can configure an array of fields to be included in the normalized result.

* means all (default) fields of the object.

You can use . to indicate sub-elements, for example user.address or user.*.

Included fields are used in two separate places:

• Normalizers that support additional fields (not provided by default) or wants to provide some optimizations, should manually check for field inclusions using passed NormalizationContext. See example below;
• after getting the normalized structure, it's filtered out leaving only the fields that were originally included.

Using this structure, following table shows what structure would be returned with different field configurations.

Usually optimizations make sense only when you make some remote calls to fetch the data or at least make any additional database calls. In this example this can be the case if Doctrine did not load the data by relation beforehand.

Denormalizing data

Denormalization is a process of converting "normalized" (plain) structures to your business objects.

This can be done when receiving JSON via some endpoint, getting the structure from MQ, database or in any other case where you want to read the normalized structure.

Normalization is initiated by using CoreDenormalizer (paysera_normalization.core_denormalizer service) denormalize method which has the following interface:

Type is required here as there's nothing to guess it from.

You can configure normalization group to use with DenormalizationContext. Same as with normalization process, make sure you pass the same CoreDenormalizer to your structured DenormalizationContext:

Registered denormalizers have one of 2 interfaces (but never both):

• object denormalizer. It's used to denormalize only from (JSON) objects. They're passed ObjectWrapper instance as a first argument;
• mixed type denormalizer. It can be used to denormalize from any structure – scalar types, arrays or objects. In case of objects, plain stdClass instances are passed, they are not converted to ObjectWrapper instances.

Normalization groups

Each de/normalizer can belong to some concrete normalization group. De/normalizers, registered without group attribute, belong to default group – this means that they are always used as a fallback.

When using customised normalization group, de/normalizer is looked for in the following algorithm:

• looking for de/normalizer with the same group as provided;
• if not found – looking for de/normalizer with default group.

This allows to easily overwrite logic for concrete normalizers, but also have the default behavior in most common use-cases.

Semantic versioning

This bundle follows semantic versioning.

Public API of this bundle (in other words, you should only use these features if you want to easily update to new versions):

• configuration of the bundle;
• only services documented in this readme;
• supported DIC tags, documented in this readme.

See Symfony BC rules for basic information about what can be changed and what not in the API.

Running tests

Contributing

Feel free to create issues and give pull requests.

You can fix any code style issues using this command: