During my work I make use of a lot of code which is out there for free. Why would you reinvent the wheel, right? But all these different components can’t possibly know about each other. So if you want to combine them you might run into integration issues. This is what happend when I was working on paginating Solr results on a website.
For my Solr setup I’m very charmed by Florian Semm’s Solr Bundle which makes Solr Documents more like Doctrine entities. You can use annotations to setup your entity’s properties and the rest is almost magic. This bundle made life so much easier that I also invested some time to do a few pull requests to improve the bundle.
On the other end I’m using the KNP University Paginator bundle. Up ’till now the bundle has helped greatly in paginating large data sets from an array or a Doctrine database result. As the document states the bundle also has support for other datasets like Solr documents.
Paginating Solr results with a new bundle
So this all sounds good, but what was the actual problem then? Even though both bundles are awesome at what they do, the Paginator bundle wasn’t able to process a Solr dataset to it’s original entities because it didn’t know about a datamapper being used. After some research I found out that KNP University has the option to create your own pagination subscribers. These subscribers can listen for an incoming data set and handle these appropriately.
This was my entry point to hook up these 2 bundles, after a few hours of coding (and coffee, and mingling with colleagues, it wasn’t all that hard) I created a new bundle called KNP Paginator Extra Bundle. For now it only contains the subscriber to solve this specific problem, but feel free to use it, expand it, improve it or learn from it. But when you do useful changes please return the love and send a pull request on Github.