Add Naming strategy for Hydrators

[ronan-gloo]

This commit is a purpose for key / properties transformations supports through externalized strategies.
It introduce the same behavior implemented for values, but on names level.

• keys / properties translations during hydration / extraction doesn't need to be hardcoded anymore in hydrators.
• Components are reusable through many hydrators.
• Despite values strategies, Only one "global" naming strategy can be defined by Hydrator.
• As side effect, non wildcard values strategies will be dependent of the naming strategy hydrate output

An Underscore <-> CamelCase strategy is shipped by default, in order to keep ClassMethods underscore feature alive, and keep the BC. (the strategy is set / unset on setUnderscoreSeparatedKeys)

For others Hydrators, you'll need to set the naming strategy manually:

$hydrator = new Zend\Stdlib\Hydrator\ObjectProperty;
$hydrator->setNamingStrategy(new Zend\Stdlib\Hydrator\NamingStrategy\UnderscoreNamingStrategy);

Let me know if you're interested to merge this feature, i'll push unit tests & doc.

[DASPRiD]

If this is a list, how can it be of type NamingStrategyInterface? Shouldn't it be an array or so?

[ronan-gloo]

I didn't updated the doc-block in the last commit, my bad.

[DASPRiD]

I like the idea in general, pretty useful in many cases.

[weierophinney]

@return self, and no empty-line between params and return annotations.

[weierophinney]

Overall, 👍

One concern I have is that hydrators then become stateful, as they have specific naming strategies composed. What I cannot recall, however, is if the HydratorManager returns a new instance each time, or the same instance; if the former, we're fine.

Also, it might be nice to have a way to pass the naming strategy when retrieving a Hydrator from the HydratorManager; plugin managers already allow passing an array of options when you call get(), and it could be used for this.

[ronan-gloo]

The Hydrator Manager return a new instance on each time be default. But you're not required to use a naming strategy, so the hydrators are still stateless from this point of view.

The idea of passing naming strategy sounds interesting, but what about filters and classic strategies ?

[weierophinney]

@ronan-gloo Ideally we should also allow passing filters and classic strategies; this would be a nice start, however. Let me know how you want to proceed.

[bakura10]

That's for this specific thing that I'd thought of Data transformers.

I'm afraid that the hydrator is getting too much features now :/. As a lot of other components may need that kind of transformation (input filters for instance), that's why I think it would be better to abstract that kind of thing "somewhere else".

[ronan-gloo]

@weierophinney That's right, as long as the interfaces are similar, it will be more flexible (but maybe a bit confusing for the user ?) to specify the "classic" StrategyInterface for naming strategy.I've separated interfaces in order to make the idea clearer.
The FilterInterface do not specify if we are in extraction or hydration context, that's why it seems to be limited as long as we don't explicitly contraints extract / hydrate filters additions in Hydration classe. Strategy interface seem's much straight forward solution to supports this feature.

@bakura10
Your general workflow suggestion for data is very interesting. Correct me if i'm wrong, but the issue for Data transformers seem's for the nest Zf release. How are your plans to integrate it for ZF2 ?

[bakura10]

@ronan-gloo , I currently have no plans integrating it into ZF2. It's just an idea though...

[weierophinney]

Since we know this is a boolean at this point (you cast it to bool in line 82), you can get rid of the true === bit.