prev/next using session & conditional query

[eluser]romero619[/eluser]
Hi,
Im trying to setup a 'photogallery browsing' page that has the following requirements:
- allows the user to enter search/filter criteria & display a paginated subset of the entire gallery
- the search results are displayed in a tiled set of thumbnail images
- clicking a thumbnail redirects the user to a separate 'photo_view' page, where a full-sized version of the thumbnailed image can be seen

- the user must be able to navigate the filtered result set by:
a) clicking the paginated navigation links on the main browsing page(s)
(example: "<< 1 2 3 4 5 6 >>")
b) clicking a "prev" or "next" button on the "photo_view" page, which should lead the user to the previous/next photo in the filtered result set...

here's an existing gallery that serves as a working example:
http://magicseaweed.com/photoLab/browsePhotos.php

requirement 'a' above is easy;
I have no problem creating a filtered sql query (using a 'where' clause), paginating the results, and creating the paginated navigation links...

my problem is requirement 'b';
I dont know how to keep track of the user's previous filter/search criteria in order to create the 'prev'/'next' buttons on the 'photo_view' sub-page(s).
As seen in the example page that I provided above, once the user exits the main browsing page by clicking a thumbnail and being redirected to the 'view_photo' page, it seems necessary to keep track of the original search query in order to scroll through the result set.

the 'magicseaweed.com' example somehow uses a 'browsing session' that keeps track of the user's position within the resultset & creates the prev/next nav links. The uid for this 'browsing session' variable can be seen in the querystring/urls for the 'prev/next' links on the full-sized photo sub-pages...
example:
-here's a 'next' button url from the 'photo_view' subpage
(link which leads to next image in filtered resultset)
http://magicseaweed.com/photoLab/viewPho...d9eca221de


I desperately need help figuring out how to set something like this up...
Im guessing this would require somehow creating a separate php session (specifically for use in browsing/searching the gallery), and storing the search results in mysql.
however, Im not sure if this is the right way to go, and I need advice on how to set this up in the most efficient way possible.

sorry if my description was confusing; please let me know if I should clarify something...
please help, thanks...

[eluser]puzzlebox[/eluser]
hmmm what seems to be the problem here?

I believe you SHOULD know the id of the Photo right? so you pass the id of the photo then do pagination there.. or did I misunderstood your question? hmmmm..

oh wait, I DID misunderstood your question.. I think it would be easier to pass the variables needed to do the query again..

[eluser]romero619[/eluser]
bump...

the goal is to avoid re-running the data query.
plus, even if I re-ran the query, I'd still need to know the exact position of the current photoID in the original result set, so that I can setup the urls to the 'prev' photoID and 'next' photoID.

Im *guessing* that I might need to setup a 'key position' array...
1) run the original data query based on user's search criteria & return an array of rows from DB
2) iterate through results array, and setup a NEW array that has 'prev' and 'next' values (sort of like a 'linked list'):

Code:

//loop over results, iterate over photoID field
for ($i=0;$i<count($data);$i++){
$picID=$data[$i]['photoID'];

//get ID's of previous & next photos foreach photo
//(for now, for simplicity, Im ignoring index bounds checking ...)
$prevID=$data[($i-1)]['photoID'];
$nextID=$data[($i+1)]['photoID'];

//populate keys array
//for use in creating 'prev & next' buttons for each photo
$keys[$picID]['prev']=$prevID;
$keys[$picID]['next']=$nextID;
}

using this 'keys' array, it would be easy to retrieve the ID values for the 'prev' and 'next' photos in the result set using the photoID of the current photo...

the question is:
how could I efficiently store this keys array & retrieve it using some sort of 'session' setup?

please help, thanks...

[eluser]jedd[/eluser]
Primarily because I'm lazy, I'm going to point you at my source, and you can work out if there's anything you can take from it - rather than the other way around.

Two things spring out that are (likely) substantially different between our starting positions / requirements.

First, my tagging information comes from an XML file that I don't own. It's the database of an application called kphotoalbum, which is a KDE app for managing images. I pull out a sub-set of information from that XML file, based on a nominated 'publish this image' tag, and then utilise a serialised version of that subset from that point on. Any update to the original XML causes a re-gen of my subset data store.

Second, one of my big criteria is that URLs are always useful - that is, it's bordering on RESTful (though not quite - some cosmetic things are stored in session data). But for the important things - position in the sub-set, offset for the thumbnails being shown, enabled filters etc - they all have to remain in the URL (and before the # - I'm very light on JS prettiness).

A caveat here - this is very much a work in progress - I'm about a fortnight away from having it ready to replace my old system. My current production image gallery is an old spaghetti code monster that I made ages ago, and am now re-writing in a nice tasty CI wrapping. Consequently I can't show you a working system anywhere that runs the code I'm pointing you at. The new code is fairly well documented, however, and you should be able to work out fairly quickly if it's of any interest to you.

Follow the [url="http://dingogully.com.au/trac/phoko"]yellow brick road[/url] to my trac page, which links to the source (git or browse directly via trac).

If you're desperately curious, it's fairly easy (from that link) to find my extant gallery system, and probably a link to the ol' crufty tarball source. The algorithms are much the same, though it's much harder to find them in my old code.