In the Symfony bundle I added interfaces representing a route generator and a factory class which creates a route generator, and I think these are good additions to the core Pagerfanta API.
When working with Pagerfanta\View\ViewInterface instances to render out pagination, you have to supply a Pagerfanta\Pagerfanta instance with the pagination data and a route generator which is responsible for building the URLs for the pagination list. How you build those generators isn't really well defined though, and right now the interface has a very loosely documented callable as its requirement. Then, for the longest time in the Symfony bundle, you couldn't really customize the route generator without overloading the entirety of the Twig integration because all of the logic was built into the Twig extension there.
Part of what I want to do with the library (well, this moreso affects framework integrations like Symfony than the library itself) is making it more API friendly to support paginated datasets and not just rendering out a pagination bar on a HTML document. The route generator definition works well for that context as well, but I don't want to encourage passing random callables around as a way of handling the construction of paginated URLs (i.e. if someone wanted to add a Link header to a response and they're using the main Pagerfanta\Pagerfanta class already, it wouldn't be hard to do something like $routeGenerator($pagerfanta->getNextPage());).
By defining an interface for a route generator builder/factory, this allows later features like moving the full Twig integration as suggested in #5 to the "core" library without hardcoding the route generating logic to a single implementation (which, in the case of the Symfony bundle, relies upon symfony/http-foundation and symfony/routing).
And, by defining an interface for a route generator, we make it much more clear how a generator should look/function. Right now the API only suggests it's a callable and you have to dig through the documentation to find the required signature for the callable, making it an interface makes it pretty clear what the API is expecting. For maximum B/C, the route generator interface only requires an __invoke() method meaning the instance will fulfill the existing callable checks.
Closes #8
In the Symfony bundle I added interfaces representing a route generator and a factory class which creates a route generator, and I think these are good additions to the core Pagerfanta API.
When working with
Pagerfanta\View\ViewInterfaceinstances to render out pagination, you have to supply aPagerfanta\Pagerfantainstance with the pagination data and a route generator which is responsible for building the URLs for the pagination list. How you build those generators isn't really well defined though, and right now the interface has a very loosely documented callable as its requirement. Then, for the longest time in the Symfony bundle, you couldn't really customize the route generator without overloading the entirety of the Twig integration because all of the logic was built into the Twig extension there.Part of what I want to do with the library (well, this moreso affects framework integrations like Symfony than the library itself) is making it more API friendly to support paginated datasets and not just rendering out a pagination bar on a HTML document. The route generator definition works well for that context as well, but I don't want to encourage passing random callables around as a way of handling the construction of paginated URLs (i.e. if someone wanted to add a
Linkheader to a response and they're using the mainPagerfanta\Pagerfantaclass already, it wouldn't be hard to do something like$routeGenerator($pagerfanta->getNextPage());).By defining an interface for a route generator builder/factory, this allows later features like moving the full Twig integration as suggested in #5 to the "core" library without hardcoding the route generating logic to a single implementation (which, in the case of the Symfony bundle, relies upon
symfony/http-foundationandsymfony/routing).And, by defining an interface for a route generator, we make it much more clear how a generator should look/function. Right now the API only suggests it's a callable and you have to dig through the documentation to find the required signature for the callable, making it an interface makes it pretty clear what the API is expecting. For maximum B/C, the route generator interface only requires an
__invoke()method meaning the instance will fulfill the existing callable checks.TODO