Rewrote paged collections with HAL

[baldurrensch]

I rewrote the way that paged collections with HAL work to be more flexible and elegant. Now, there is an interface Model/PagedCollectionInterface.php that needs to be implemented. There is also a concrete class Model/PagedCollection.php that can be inherited from that already has the getters and setters implemented. This interface or class can be used to create custom paginated results. That way, we can use annotations to create additional links for the resources, as well as additional properties (or embedded objects).

This still needs:

• [ ] Documentation
• [ ] Updated Unit tests
• [ ] The old HalPager needs to be removed, and I want to rename the Handler to PagedCollectionHandler at that point
• [ ] There are also unit tests failing because of deprecated functions in Symfony. I'll open a separate PR to fix those. This needs to be rebased afterwards.

[adrienbrault]

I don't think that creating a serializer handler for an interface makes sense.

It would be misleading, what if someone creates a class, adds some properties with serializer metadata, and implements the PagedCollectionInterface ? The properties and their metadata will be ignored and only the collection stuff will be serialized (the links will also be serialized because they're added via an eventsubscriber).

[baldurrensch]

So, should I then just get rid of the interface and bind the listener to the class itself?

[adrienbrault]

@baldurrensch What's the advantage of the interface here instead of extending from the current HalPagerfanta ?

[baldurrensch]

I figured it would provide more freedom.

[baldurrensch]

Yeah, I think at first I wanted to keep both for BC. Then, I wanted to get rid of it. But actually they are totally BC. So maybe, I just need to improve the HalPagerfanta (don't like the name though, but anyways), and adjust the other small changes. What do you think?

[adrienbrault]

You can rename it if you want, we'll just have to increase the version.

[baldurrensch]

Not needed anymore. The current solution with @JMS\Inline is way superior.