We are no longer using Apigility at PHPro anymore. Therefor, it is hard for us to make the correct decisions for this package. We are looking for someone who wants to take over the package and can push it in the correct direction again.
Are you that person? Reach out and we'll discuss how we can help each other!
Feel free to use it AS-IS, we won't be providing any support anymore.
Doctrine Hydration Module
This module provides a configurable way to create new doctrine hydrators. By using the configurable API, it is easy to create a custom hydrator for any use case you want.
For ORM, the basic hydrator from the doctrine module is being used. It is possible to configure your own strategies for complex objects like referenced entities.
For MongoDB ODM, a specific hydrator is added. This hydrator will be able to handle Referenced documents and Embedded Documents. It is also possible to hydrate advanced documents with discriminator maps.
- 4.0.x: Contains zend-servicemanager >=3.3.2 support requiring PHP 5.6+.
- 3.0.x: Contains zend-servicemanager >=3 support requiring PHP 5.6+.
- 2.0.x: Contains zend-hydrator support requiring PHP 5.6+.
- 1.0.x: Contains zend-stdlib <2.7 support requiring PHP 5.4+.
Make sure to commit on the correct branch if you want your changes to get merged into the project.
Add to composer.json
composer require phpro/zf-doctrine-hydration-module
Add to application config
return array( 'modules' => array( 'Phpro\\DoctrineHydrationModule', // other libs... ), // Other config );
return array( 'doctrine-hydrator' => array( 'hydrator-manager-key' => array( 'entity_class' => 'App\Entity\EntityClass', 'object_manager' => 'doctrine.objectmanager.key.in.servicelocator', 'by_value' => true, 'use_generated_hydrator' => true, 'naming_strategy' => 'custom.naming.strategy.key.in.servicemanager', 'hydrator' => 'custom.hydrator.key.in.hydratormanager', 'strategies' => array( 'fieldname' => 'custom.strategy.key.in.servicemanager', ), 'filters' => array( 'custom_filter_name' => array( 'condition' => 'and', // optional, default is 'or' 'filter' => 'custom.hydrator.filter.key.in.servicemanager', ), ), ), ), );
This property is used to specify the class of the entity that will be hydrated. You need to make sure that this entity is a mapped doctrine class.
You can specify which object manager you want to use for the hydrator. The value is the key of the desired object manager in the service manager.
Specify if you want the hydrator to hydrate the entity by value or by reference.
This property will only be used with mongoDB ODM and will use the generated hydrators instead of the Doctrine Module Hydrator.
Strategies will not work when this option is set to
You can use a custom naming strategy for the hydrator. Specify the key of the naming strategy in the service manager.
Note that this naming strategy needs to implement
You can use a custom hydrator instead of the default
Make sure this hydrator implements
It is possible to customize the hydration strategy of specific properties.
Configure the property you want to customize with the key of the strategy in the service manager;
Note that this strategy needs to implement
This property can be used to apply filters on the Hydrator.
You can specify a list of custom filters by defining the key of the filter in the service manager and the filter condition as described in the hydrator filter documentation.
Note that this filter needs to implement
From here on, you can get the hydrator by calling
get('hydrator-manager-key') on the HydratorManager.
- DateTimeField: Used for DateTime objects
- DefaultRelation: Leave the relation AS-IS. Does not perform any modifications on the field.
- EmbeddedCollection: Used for embedded collections
- EmbeddedField: Used for embedded fields
- ReferencedCollection: Used for referenced collections
- ReferencedField: Used for referenced fields.
- EmbeddedReferenceCollection: This is a custom strategy that can be used in an API to display all fields in a referenced object. The hydration works as a regular referenced object.
- EmbeddedReferenceField: This is a custom strategy that can be used in an API to display all fields in a referenced object. The hydration works as a regular referenced object.
Custom filters allow you to fine-tune the results of the hydrator's
extract functionality by determining which fields should be extracted.
To configure custom filters:
return array( 'doctrine-hydrator' => array( 'custom-hydrator' => array( // other config 'filters' => array( 'custom.filter.name' => array( 'condition' => 'and', //optional, default: FilterComposite::CONDITION_OR, 'filter' => 'custom.filter', // a name in the Service Manager ), ), ), ), );
In this example configuration, the hydrator factory will retrieve
custom.filter from the Service Manager and inject it as a filter into the hydrator. The filter must implement
filter($fieldName) function will be called by the hydrator during
extract and the field name being extracted will be passed as an argument. The
filter() function must return a truthy value: if
true then the field will NOT be extracted.
If the standard DoctrineHydrator is not flexible enough, you can set a custom
hydrator. This allows you to use an extended DoctrineHydrator or another existing hydrator, and configure it with this module. This setting will override
return array( 'doctrine-hydrator' => array( 'custom-hydrator' => array( // other config 'hydrator' => 'Zend\Hydrator\ArraySerializable' ), ), );
This package is fully tested with Cs fixer and PhpUnit. The MongoDB tests require mongodb to be installed on your machine. You can skip these tests by adding a testsuite to the command:
# Php coding standards: # (The files are loaded according to the PSR-4 standard. The PSR-0 fix will fail!) ./vendor/bin/php-cs-fixer fix . --dry-run --fixers=-psr0 # Phpunit: ./vendor/bin/phpunit # Testing one testsuite: ./vendor/bin/phpunit --testsuite="Main" ./vendor/bin/phpunit --testsuite="ODM"