Adding custom data to a collection - Approaches suggested in mailing list feel wrong

[jackdpeterson]

@weierophinney mentioned a few approaches to getting additional metadata into a collection in the mailing list. While both technically valid and sufficient ways to get the job done ... they both feel wrong from two perspectives:

Approach 1 - return a ZF\Hal\Collection object directly from a resource.
--> downside here is that it loses the pagination information without extra work to get it fully configured. This feels like reinventing a wheel that Apigility already has works just fine. This probably wouldn't be so bad if this was a well documented approach in terms of adding in the pagination information where it reads from the configuration.

Approach 2 - use an rendering event and make modifications to the collection if it is an instanceof X collection.
--> The downside here is that the logic for this gets placed in a spot that is completely unrelated to the area where one would expect modifications to go (the resource, or the domain model if more complex). Typically, one would tie this event stuff in their module.php file around the onBootstrap method with extra handler methods. For developer B who has to work with / extend the code taken from developer A, those extra attributes would appear in a way that would seem like magic -- coming from nowhere. Furthermore, if one is reaching inside of a domain model ... the service locator must once again fetch dependencies to make that logic completable.

Is this something that can be planned for or at least get a better / documented approach for the 2.0 Apigility release?

[weierophinney]

This repository has been closed and moved to laminas-api-tools/api-tools; a new issue has been opened at laminas-api-tools/api-tools#20.