How many people use pagination and say have a filter to reduce the results down? I know I use this a lot but am having huge problems when it comes to passing all this data around in the uri so I can return the user to the correct page after say they modify a record.

Its just not possible to keep passing all this data around through the uri like I would have done if I had GET variables (I know I could turn them on, but then it means the use of urls through the application isn’t consist, which I don’t want). So does anyone have any clever idea’s of how to pass all this data around?

The data that would need to be passed would be, what offset you are on and any current filter options.

I was thinking if it was stored in flash sessions that may work, but what happens say if you are on the last link of a pagination trail and there is only 1 row. If you delete that row how will it know where to return to, since if it goes to the page it was on then it would be invalid, due to no rows for that page.

This was getting discussed slightly on another post but I didn’t want to hi-jack it any more than I had done already.

In case of the last page invalid problem after manipulation you can check if the pagenumber is smaller than the page count. If it’s more you an do a redirect to the previous page.

I’ve just looked at the pagination library code and it already does that check so there is no need for my snippet.

What about the issue of passing filter data around. Would using normal GET queries be the best option then?

Yeah, how’s this supposed to be done? *tired*

I don’t know I haven’t tried yet, I keep putting it off since I know its a pest.

I have done some thinking the last few days and have decided I don’t want to do the GET query unless I have to.
I think I am try to store them in a database table e.g search_filters. So I would store the following when someone sumits a search filter request:

- session_id
- md5 hash of base url, e.g just hash the controller/method bit.
- Time the search was done at
- A serialized array of the filter parameters

This way when a page is loaded, (which has filter options) call a library function which checks if there is any filter options for the current page and user, and runs the correct AR query strings. Filter searches could expire after 10mins or so.

As said I haven’t tried this but it seems a relatively simple library to create.

This can be tricky. You could save the query in a session and then append to it a LIMIT statement depending on what set of pages you need to view, then call this in the pagination.

Basically I think the storing it in a session is exactly the same as a DB table, suppose an advantage of in the session would be less database calls.

I just also thought you don’t need to store the time since when a user creates a new filter, they aren’t looking at the old table so you can overwrite the old filter.

Less database calls is exactly the advantage of storing it in a session, and it is much simpler.

if a new search is submitted create the sql string and store it in a session var

else

if a session var is set get the sql from that.

A new search overwrites the previous one for that session - if you want to save them for future use - then store them in a database.

You will have to store a hash of the page, otherwise when you first visit a new table it won’t otherwise know if it should use a current filter or a default filter for the new table.

Could you use table name as prefix to session var, this way multiple tables would have their own cached queries.

I did it the session way, it seems simpler than creating an extra table. Ah, a library. Brilliant! I should think more OOP and less ugly code.

adamp1: “... after say, they modify a record.”
To return to a filtered view (or just to store filter settings), why not
use a hidden field in the edit-form with some “returnToPage…” or
“cameFromPage” information you can use to show the next step.
- (make sure you do not INSERT INTO the database all the formfields,
  sanatize and validate!

Problem is you still have to pass this data to the form to put it in the hidden filed. Which complicates the URL, and when using pagination as well it gets more complicated.

I expanded the pagination class a bit so it does accept GET parameters. I found for filtering this is the best option. Even if some people dont’t like it. In some situatione GET is still the easiest solution and used by most web apps by the way…