Hi, let me start briefly by saying that I've been using PHP on and off for a while but just recently have started using it full time on the job. Unfortunately, I've missed out on all the framework development that's been going on for the last decade. I've settled on Fuel (for now at least) but if I sound like I've missed some common theme, I probably have so please bring it up.
I'm trying to rewrite a web app utilizing an existing database. Just trying to do really simple stuff at the moment, and I've gotten hung up once I reached pagination of search results. I'm using GET for the search form and it seems the Pagination class just doesn't play with query strings well. One suggestion on the forums is to just store the queries in the session on the server. I suppose this would work but it doesn't sound very RESTful, you couldn't bookmark a result page or pass the link to someone else.
It appears the FuelPHP forums store the search terms server side somehow and then refer to them in a URI segment with a unique id. This just sounds a bit excessive for a simple search. Can I easily do something like "http://stackoverflow.com/search?page=2&tab=relevance&q=fuelphp"; using Fuel without re-inventing the wheel everywhere?
Note, my main question is not "Why can't I do it my way?" but rather, I'm looking to learn, how do the Fuel developers envision their framework would be best used in such a situation?
Thanks.
There's a few different takes on this.
In many cases rerunning the same search many times over can be very taxing on your database and system, especially when using LIKE on large text fields or full text searches. In such cases a cached approach is often used: the search is ran once and the full resultset is cached after which the URL consists of an id for the cached result (often a hash of the search string) and a page number. This isn't RESTful but will save you many heavy queries that might tax your database too harsh when many users are active.
If you want your search & the results truly RESTful you'll have to keep running it and indeed need to have all the params in a request. To be honest as far as I know none of us core devs actually uses the Pagination class and it has been marked for a big simplification and more template-based overhaul. In your case I'd start with this not using the Pagination class and see about using it later if at all.
(About pagination, in my case I use a template based approach along with JS to generate it - no pagination-specific classes/objects are involved on the server side)
Donate
