standard hydrator idea

[ojhaujjwal]

I created this hydrator and named it as StandardHydrator. This is just an idea. This name can be changed if you guys like the idea.

class Album
{
    public function getId()
    {
        return 34;
    }
}

class Artist
{
    public function getName()
    {
        return 'David';
    }
}


$albumHydrator = new Zend\Stdlib\Hydrator\ClassMethods;
$artistHydrator = new Zend\Stdlib\Hydrator\ClassMethods;

$hydrators = new Zend\Stdlib\Hydrator\HydratorPluginManager;
$hydrators->setService('Album', $albumHydrator);
$hydrators->setService('Artist', $artistHydrator);

$standardHydrator = new Zend\Stdlib\Hydrator\StandardHydrator($hydrators);

$standardHydrator->extract(new Album); // returns ['id' => 34];
$standardHydrator->extract(new Artist); // returns ['name' => 'David'];

This detects the hydrator for each object. I think that this hydrator can be pretty useful.

[Ocramius]

Very interesting approach, though I'm not sure if I like it (I still have to think about it).

Not agreeing with the naming: should probably be a SelectingHydrator or such (and yes, this name is horrible as well).

[ojhaujjwal]

I think one interesting use case for this hydrator is zfr-rest module. Maybe this. Each entity has one hydrator associated with it.

[macnibblet]

I like the concept, but not the implementation as it will cause confusion. One should not use the DiC to map a object to it's hydrator.

@Ocramius Not sure why you tagged this with ServiceManager ?

[Ocramius]

@Ocramius Not sure why you tagged this with ServiceManager ?

It effectively introduces the ServiceManager in stdlib context.
As for the implementation, I don't have anything against using a PluginManager as backing mechanism, but the dependency between components is worrying me.

[macnibblet]

@Ocramius Uhm ServiceManager is already in Stdlib since we have Zend\Stdlib\Hydrator\HydratorPluginManager

[Ocramius]

Urgh, that sucks :-\

[ojhaujjwal]

Now, I am thinking to create a service factory for this hydrator here . Any thoughts?

[ojhaujjwal]

I created a factory too. Please do comment. :)

[Ocramius]

@ojhaujjwal I'd say it fits a module, not the standard Mvc.

[ojhaujjwal]

are you disagreeing with adding the factory in the Mvc component? I really didn't get it.

[macnibblet]

@ojhaujjwal Yes, it does not belong in the mvc component.

[ojhaujjwal]

But, wait. How do other services like HydratorManager belong to Mvc?

[jaapio]

I do not see why this is better that just using the hydrator manager to get a hydrator for your entity class. Which is basically what you do when you use the StandardHydrator Class.

[ojhaujjwal]

Any more comments?

[weierophinney]

This could actually replace the functionality we have in our metadata_map inside zf-hal. The key difference zf-hal proposes is that it also does some lookups based on inheritance tree, IIRC.

I, too, am not a fan of the verbiage StandardHydrator, and think something along the lines of SelectingHydrator or MappingHydrator would be more self-describing.

@ojhaujjwal 👍

• Please rebase against the current develop branch
• Rename to one of the above options

and I'll include this in 2.4 (and update zf-hal to make use of it!).

[macnibblet]

@weierophinney can you please explain why this component belongs in mvc ? I don't see a reason to include it just so something can be removed from a apigility component ?

[sandrokeil]

@weierophinney What's with the name DiscoveryHydrator?

[ojhaujjwal]

MappingHydrator is better IMO!

[ojhaujjwal]

@weierophinney rebasing part is done! :D

[weierophinney]

@weierophinney can you please explain why this component belongs in mvc ?

I missed that the factory was in the MVC component - it should be under the Zend\Stdlib\Hydrator namespace. @ojhaujjwal one more change to make...

I don't see a reason to include it just so something can be removed from a apigility component ?

@macnibblet — It's not just Apigility; I've actually seen a number of people wanting to use the hydrator mapping aspect of zf-hal for other purposes, but it's not separated. This would provide that separation. It would also allow us to use the mapping aspect for vanilla JSON responses, for which we don't have a serialization strategy (other than JsonSerializable) in Apigility currently due to the aforementioned coupling in zf-hal — but in a way that could be put into a specialized JSON renderer.

What's with the name DiscoveryHydrator?

Um, @sandrokeil, I don't know... you're the first to bring that up. Are you suggesting it as a name for the hydrator?

[sandrokeil]

@weierophinney Yes, it's another suggestion for the hydrator name.

[stefanotorresi]

I think this check should be removed, as it can lead to unpredictable behaviour as explained in zfcampus/zf-hal#86

The plugin validation is already done by the plugin manager, calling has on a pluginmanager with $autoAddInvokableClass on by default can lead to inconsistent results.

[weierophinney]

Good point; @ojhaujjwal — please update accordingly. Essentially, we can rely on the fact that the hydrator plugin manager will raise an exception here.

[stefanotorresi]

As a name I would personally something like DelegateHydrator, DelegatorHydrator or HydratorDelegator, as it follows the delegator pattern quite closely.

MappingHydrator may be misleading, since there isn't actually any map involved.

[weierophinney]

As a name I would personally something like DelegateHydrator, DelegatorHydrator or HydratorDelegator, as it follows the delegator pattern quite closely.

I was suggesting "map", as I was thinking of the feature with regards to the metadata_map of zf-hal... but that map is for more than just hydrators; in fact, hydrators are a part of that map.

I'm personally wavering between "Discovery" and "Delegating"; I'll choose one during merge.

[jaapio]

+1 for Delegating, since the actual hydration is deletaged to another hydrator

[malukenho]

Trim spaces

[weierophinney]

I'm reviewing now, and have noticed that the patch still contains additions to the MVC ServiceListenerFactory. I think the more appropriate route is to expose the new hydrator via the HydratorPluginManager, and feed it the parent service locator if present. I will attempt to make that adaptation during merge.

[weierophinney]

Merged for release in 2.4.

Renamed the new hydrator to DelegatingHydrator, per consensus in the comments. Additionally, you now pull it from the HydratorPluginManager (the HydratorManager service) instead of the application ServiceManager instance.

Usage is now:

$hydrators = $services->get('HydratorManager');
$delegating = $hydrators->get('DelegatingHydrator');
$albumHydrator = new Zend\Stdlib\Hydrator\ClassMethods;
$artistHydrator = new Zend\Stdlib\Hydrator\ClassMethods;

$hydrators = new Zend\Stdlib\Hydrator\HydratorPluginManager;
$hydrators->setService('Album', $albumHydrator);
$hydrators->setService('Artist', $artistHydrator);

$array = $delegating->extract(new Artist);
$artist = $delegating->hydrate($data, new Artist);

@ojhaujjwal Please also submit documentation to https://github.com/zendframework/zf2-documentation 😄