[WIP] Hydrator and resource serialization

[bakura10]

I want to do correctly the hydration stuff, both for extraction and hydration.

Here are the features that we need to implement properly:

1. Allow to support kind of "naming scheme". This naming scheme is used for extraction (when the user return an object from a controller) and hydration (when data is sent from the client to the server). Those naming scheme defined how the JSON (question: what about XML? as of today ZF has no support for XML, so maybe it's simpler if we only support JSON) is formed. Following things must be taken into account : what is the style of keys (underscore_separated, camelCased...), should the resource be wrapped around a key, how associations are done (embedded, id...).
2. Being able to hydrate/extract data that is wrapped around paginator, collection... For instance, we may have a Paginator in the controller, we should be able to hydrate/extract it, so that it automatically outputs data specific to the paginator and data specific to the resource. This may be a use for the new AggregateHydrator.

At some point, those objects would use the resource metadata that contains various information from mapping (for instance how a given association should be represented). So we most likely have a custom Paginator class that extends Zend\Paginator and hold metadata or something like that.

@Ocramius , is this something you could work on ? I'd be happy to update the current doc to reflect my latest changes so that you can use it more quickly.

[Ocramius]

Allow to support kind of "naming scheme". This naming scheme is used for extraction (when the user return an object from a controller) and hydration (when data is sent from the client to the server). Those naming scheme defined how the JSON (question: what about XML? as of today ZF has no support for XML, so maybe it's simpler if we only support JSON) is formed. Following things must be taken into account : what is the style of keys (underscore_separated, camelCased...), should the resource be wrapped around a key, how associations are done (embedded, id...).

Hydration is not a problem related with XML. That's done in a later step. For the naming/nesting, the transformation could be applied after extraction or before hydration. The Aggregate hydrator supports events for that, so it should be ok-ish. The transformation is just a much smarter array_map if you think about it ;)

Being able to hydrate/extract data that is wrapped around paginator, collection... For instance, we may have a Paginator in the controller, we should be able to hydrate/extract it, so that it automatically outputs data specific to the paginator and data specific to the resource. This may be a use for the new AggregateHydrator.

That's why we have it, perfect!

At some point, those objects would use the resource metadata that contains various information from mapping (for instance how a given association should be represented). So we most likely have a custom Paginator class that extends Zend\Paginator and hold metadata or something like that.

Custom paginator? Not sure why this would be needed here - is it about building pagination links?

[bakura10]

Custom paginator? Not sure why this would be needed here - is it about building pagination links?

I thought about having a ZfrRest paginator, where you could inject the resource metadata here:
https://github.com/zf-fr/ZfrRest/blob/master/src/ZfrRest/Mvc/Router/Http/ResourceGraphRoute.php#L241

Therefore, when outputing data in the extract of the hydrator, we can have access to the metadata.

[Ocramius]

@bakura10 I see. Looks ok to me