search

TheFootballSocialClub / FSCHateoasBundle

Please use https://github.com/willdurand/hateoas and https://github.com/willdurand/BazingaHateoasBundle instead.
94 stars 26 forks source link

[Enhancement] Implement handling KnpPagination and Doctrine Paginator #47

Open benbender opened 11 years ago

benbender commented 11 years ago

I would like to know if there is any special reason why this bundle is bound to Pagerfanta? As far as I saw from a quick look into the RelationsManager, only the current and max page are needed from the paginator and it shouldnt be that hard to get broader support into the bundle. The only catch would be the existing type-hinting and BC if I'm not overseeing something.

I'm interested in getting support for, at least, KnpPaginator into the bundle because I'm using it all over the place and love the sorting- and filtering-capabilities.

Another candidate for implementation would be the new Doctrine Paginator.

baldurrensch commented 11 years ago

Pagerfanta and KnpPaginator both make use of the Doctrine Paginator from what I know. It would make sense to add support for generic pagination, but that is a little bit of work.

benbender commented 11 years ago

Doctrine Paginator is a concrete implementation and no interface. So its only used by KNP and Pagerfanta for there ORM/ODM-stuff. Things like array, solarium and probably others are not affected by these changes. Unfortunatly. So only changing the implementation to Doctrine Paginator would not solve the root issue to get a more generic pager-handling into the bundle :/

stof commented 11 years ago

Doctrine Paginator is ORM specific actually, not even ODM. and it is mainly meant as a low level tool to be used in higher level pagination libraries (you will often want to expose a page, not a limit and an offset).

What the bundle could do is expecting its own interface for this, with implementations of the interface wrapping Pagerfanta or Knp Paginator

benbender commented 11 years ago

+1 for @stof s proposal!