Photo album logic

I have an online photo album (like everyone else and their dog) and I'm
wanting to work out an 'elegant' solution to some of the logic. What I'm
trying to accomplish is not having a long URL as I step through single
pictures.

I'll try to explain how it is now and why I'd like it changed...

First page of the album is a list of picture sets with a thumbnail to
represent each set. The sets are split 15 per page (currently 39 sets) so
ends up with 3 pages. As I step through the pages I send $page on to the
next page to be incremented and use that to decide which sets I display
next. I've put my next page link logic up before, but that part isn't all
that important at the moment. Bottom line is I use SQL's LIMIT function to
get 15 at a time and use the $page var to decide where to start.

Once you click on a set, you see thumbnails for that set and again get to
step through pages. (also split at 15 per page)

Then you can step through the thumbnail pages and then click on a single
image to see it larger.

Typical so far.

At any point in this path, I have a 'parent' link that takes you up a level.
It's not just a 'back' step, it's back to the previous level... so if you're
on a single image it takes you back to the thumbnails for that set and if
you're looking at thumbnails it takes you back to the list of sets.

All fine so far except I want to be able to keep track of the page I came
from for both the sets and the thumbnails. I'll try to lay out a sample
situation below:

start on SET page 1
*click next
SET page 2
*click next
SET page 3
*click set ID 101
THUMB page 1 for SET 101
*click next
THUMB page 2 for SET 101
*click image ID 901
IMAGE page ID 901


At that point I want to be able click a 'back to thumbnails' link and go
back to THUMB page 2, then from there click a 'back to sets' link and go
back to SET page 3. I don't want the 'back' links to take me to page 1,
instead I want it to take me to the page in the sequence I was at when I
clicked further in.

I currently have it working, but end up with a URL like this:

bob.php?setpage=3&thumbpage=2&imageid=901

I just think that's kind of 'dirty'. Am I on crack and that's just how it
should be? Or is there a better way?

I thought about using a cookie, but would that make sense to write to a
cookie every time you click next? I didn't think so, but maybe? I thought
about POST to clean up the address bar, but that increases my code for each
link and it's dirty in it's own right with refreshes needing re-posted.

What about encoding the URL to something short and sweet, then decoding it
on each page? That seems kind of overkill and dirty too at this point since
I'd end up with a 30 character string to pass on, right?

I'm just trying to make this as 'clean' and 'elegant' as possible. Right
now it just feels pretty freshman... although that's what I am in PHP
anyway, but I'd like not to be.

Thanks in advance for any input!


--
Shawn Wilson

Shawn Wilson said the following on 27/09/2005 23:29:
> I have an online photo album (like everyone else and their dog) and I'm
> wanting to work out an 'elegant' solution to some of the logic. What I'm
> trying to accomplish is not having a long URL as I step through single
> pictures.

<...SNIP...>

> At any point in this path, I have a 'parent' link that takes you up a level.
> It's not just a 'back' step, it's back to the previous level... so if you're
> on a single image it takes you back to the thumbnails for that set and if
> you're looking at thumbnails it takes you back to the list of sets.
>
> All fine so far except I want to be able to keep track of the page I came
> from for both the sets and the thumbnails. I'll try to lay out a sample
> situation below:
>
> start on SET page 1
> *click next
> SET page 2
> *click next
> SET page 3
> *click set ID 101
> THUMB page 1 for SET 101
> *click next
> THUMB page 2 for SET 101
> *click image ID 901
> IMAGE page ID 901
>
>
> At that point I want to be able click a 'back to thumbnails' link and go
> back to THUMB page 2, then from there click a 'back to sets' link and go
> back to SET page 3. I don't want the 'back' links to take me to page 1,
> instead I want it to take me to the page in the sequence I was at when I
> clicked further in.
>
> I currently have it working, but end up with a URL like this:
>
> bob.php?setpage=3&thumbpage=2&imageid=901
>
> I just think that's kind of 'dirty'. Am I on crack and that's just how it
> should be? Or is there a better way?

A few thoughts:

* You could just rely on the Back button on the user's browser! That's
what it's there for ;)

* You could save a "history" in $_SESSION.

* In the example URL above, I would've thought you could determine the
thumb-nail page from the imageID alone, and the Set Page from the
thumb-nail page alone.
i.e. to get to imageid 901, the user *must* have come from thumbpage 2.
And to get to thumbpage 2, they *must* have come from setpage 3.
Therefore, you should always be able to ascertain where to link back to.



--
Oli

"Oli Filth" <catch@olifilth.co.uk> wrote in message
news:Cok_e.694$Nv6.18@newsfe6-win.ntli.net...
> A few thoughts:
>
> * You could just rely on the Back button on the user's browser! That's
> what it's there for ;)

The back button would take them back a page of thumbnails if they are more
than one page in... i.e. if they go to page 3, then click an image, they
could click back to get back to page 3 of the thumnails, but then would have
to click back 3 more times to get back to the set list. That's why I don't
use the back button.

>
> * You could save a "history" in $_SESSION.
>

That's what I'm looking for I think. I haven't used session variables yet
and I'm a little unclear about what type of things get set on the client's
side and what stays on the server. I'd like this info to stay on the
server if I can so I'm not constantly writing to the client.

> * In the example URL above, I would've thought you could determine the
> thumb-nail page from the imageID alone, and the Set Page from the
> thumb-nail page alone.
> i.e. to get to imageid 901, the user *must* have come from thumbpage 2.
> And to get to thumbpage 2, they *must* have come from setpage 3.
> Therefore, you should always be able to ascertain where to link back to.

That's not always the case. In this case I'm using 15 images per page so I
can extrapolate the page, but I may not always use 15 images per page and I
want to be able to change the number of images per page without recoding
anything.

--
Shawn Wilson

"Shawn Wilson" <firstinitial_lastname@dvigroup.net> wrote in message
news:Mzk_e.131627$Fp4.51596@fe09.news.easynews.com ...
> "Oli Filth" <catch@olifilth.co.uk> wrote in message
> news:Cok_e.694$Nv6.18@newsfe6-win.ntli.net...
>> A few thoughts:
>>
>> * You could just rely on the Back button on the user's browser! That's
>> what it's there for ;)
>
> The back button would take them back a page of thumbnails if they are more
> than one page in... i.e. if they go to page 3, then click an image, they
> could click back to get back to page 3 of the thumnails, but then would
> have to click back 3 more times to get back to the set list. That's why I
> don't use the back button.
>
>>
>> * You could save a "history" in $_SESSION.
>>
>
> That's what I'm looking for I think. I haven't used session variables yet
> and I'm a little unclear about what type of things get set on the client's
> side and what stays on the server. I'd like this info to stay on the
> server if I can so I'm not constantly writing to the client.
>
>> * In the example URL above, I would've thought you could determine the
>> thumb-nail page from the imageID alone, and the Set Page from the
>> thumb-nail page alone.
>> i.e. to get to imageid 901, the user *must* have come from thumbpage 2.
>> And to get to thumbpage 2, they *must* have come from setpage 3.
>> Therefore, you should always be able to ascertain where to link back to.
>
> That's not always the case. In this case I'm using 15 images per page so
> I can extrapolate the page, but I may not always use 15 images per page
> and I want to be able to change the number of images per page without
> recoding anything.

I've been playing with $_SESSION and I have come across what seems strange
to me but hopefully one of you understands and can explain it to me.

I put together 4 pages based on info from the manual and the PHPSESSID is
inconsistent in showing up in the address bar while the variables seem to
follow just fine. Am I doing something wrong? (I'd prefer the ID not be
there if that's a choice) But why is it showing up and then going away?

Page one:
--------------------------
<?php
session_start();
$count = 5;
$_SESSION["count"] = $count;
$count2 = 10;
$_SESSION["count2"] = $count2;
?>

<br>
Count is set to: [<?=$count?>].<br>
<br>
To continue, <a href="nextpage.php">click here</a>.<br>
--------------------------

Page 2, 3, and 4 all look like this:
--------------------------
<?php
session_start();
?>

<br>
Count is set to: [<?=$count?>].<br>
Count2 is set to: [<?=$count2?>].<br>
<br>
To continue, <a href="nextpage2.php">click here</a>.<br>
--------------------------

When I click on the link from the first page, the second page shows the ID
in the URL. When I click on the link in the 2nd page and beyond, the ID is
not in the URL anymore. However the variables still follow.

Page one is making the link with the ID in it - which I understand is
automatic because that option is turned on on my server, however why do the
following pages not auto-add the ID and why does it work even without the
ID?


--
Shawn Wilson

>> * In the example URL above, I would've thought you could determine the
>> thumb-nail page from the imageID alone, and the Set Page from the
>> thumb-nail page alone.
>> i.e. to get to imageid 901, the user *must* have come from thumbpage 2.
>> And to get to thumbpage 2, they *must* have come from setpage 3.
>> Therefore, you should always be able to ascertain where to link back to.
>
> That's not always the case. In this case I'm using 15 images per page so I
> can extrapolate the page, but I may not always use 15 images per page and I
> want to be able to change the number of images per page without recoding
> anything.


With your current link content:

>>> bob.php?setpage=3&thumbpage=2&imageid=901

you do not have this too. I mean if someone changes his settings for
"thumbnails for page" while looking at image 901, than the "thumbpage=2"
will lead them to the different place than that which they got from.

If you only want to go to the "thumbpage" which will containg the
image 901 accorfing to their current "thumbs per page" settings, then
the Oli Fith's solution will work (you calculate which image in the
set is the current image, then divide it by the "thumbs per page"
number, round up and get the page number, same with "setpage").

Remembering the page number will not work correctly when changing
"thumbs per page" in URLs and also in $_SESSION. Only solution
is to calculate the page number "on the fly" based on the current
image ID or thumbpage number. You could also record the ID of
the first image on the thumbpage they are comming from and use
it as the first image on the thumbpage they are returning to
(after changing the "thumbs per page" setting), but this may lead
to incomplete first page when going to it with clicking "previous
page" page.


Hilarion

"Hilarion" <hilarion@SPAM.op.SMIECI.pl> wrote in message
news:dhgucc$1fa$1@news.onet.pl...
>>> * In the example URL above, I would've thought you could determine the
>>> thumb-nail page from the imageID alone, and the Set Page from the
>>> thumb-nail page alone.
>>> i.e. to get to imageid 901, the user *must* have come from thumbpage 2.
>>> And to get to thumbpage 2, they *must* have come from setpage 3.
>>> Therefore, you should always be able to ascertain where to link back to.
>>
>> That's not always the case. In this case I'm using 15 images per page so
>> I can extrapolate the page, but I may not always use 15 images per page
>> and I want to be able to change the number of images per page without
>> recoding anything.
>
>
> With your current link content:
>
>>>> bob.php?setpage=3&thumbpage=2&imageid=901
>
> you do not have this too. I mean if someone changes his settings for
> "thumbnails for page" while looking at image 901, than the "thumbpage=2"
> will lead them to the different place than that which they got from.
>
> If you only want to go to the "thumbpage" which will containg the
> image 901 accorfing to their current "thumbs per page" settings, then
> the Oli Fith's solution will work (you calculate which image in the
> set is the current image, then divide it by the "thumbs per page"
> number, round up and get the page number, same with "setpage").
>
> Remembering the page number will not work correctly when changing
> "thumbs per page" in URLs and also in $_SESSION. Only solution
> is to calculate the page number "on the fly" based on the current
> image ID or thumbpage number. You could also record the ID of
> the first image on the thumbpage they are comming from and use
> it as the first image on the thumbpage they are returning to
> (after changing the "thumbs per page" setting), but this may lead
> to incomplete first page when going to it with clicking "previous
> page" page.
>
>
> Hilarion

The user won't be setting the thumbs per page option, I will as the album
admin. I could calculate what page a particular image would fall on and
always be right. However, that would take three steps:

1. sql to get list of picids
2. find the current picid in that array (finding that it's picture number
32)
3. divide per page number by the location step 2 found and rounding up

That just seems like an aweful lot of code to figure it on the fly when I
could pass the last page you touched on to the next page one line of code.

Keeping in mind that I never indicated that the picids were perfectly
sequential. They usually will be, but if I delete a picture or add one
later then that would introduce picids that were not perfectly meaning of
their position in the set. I can't rely on assuming that picid 32 is
actualy the 32nd picture in a set. If I deleted a previous pic, then number
32 might now be in the 31st position unless I rename all my pictures
everytime I remove one - and that seems like overkill.

$SESSION variables seem like the way to go since the user can't change the
thumbs per page, only I can, and even if they could, it wouldn't be on the
fly, they'd have to go to a 'settings' menu and start their browsing over
again so the $SESSION problem mentioned won't be an issue for me.

My problem at this point though is properly using $SESSION as I stated in a
message parallel to yours in the reply tree.

I've got a seperate thread started on clarifying $SESSION usage so I won't
state it again here.

Thanks for the input guys.

--
Shawn Wilson

> The user won't be setting the thumbs per page option, I will as the album
> admin. I could calculate what page a particular image would fall on and
> always be right. However, that would take three steps:
>
> 1. sql to get list of picids
> 2. find the current picid in that array (finding that it's picture number
> 32)
> 3. divide per page number by the location step 2 found and rounding up
>
> That just seems like an aweful lot of code to figure it on the fly when I
> could pass the last page you touched on to the next page one line of code.

That can be done in single SQL query in Oracle 8i.


> Keeping in mind that I never indicated that the picids were perfectly
> sequential.

I didn't assume that.


> They usually will be, but if I delete a picture or add one
> later then that would introduce picids that were not perfectly meaning of
> their position in the set. I can't rely on assuming that picid 32 is
> actualy the 32nd picture in a set.

I know. Also because the pictures may be ordered by name/description/date,
not by ID on the page. I assumed only that we have the information
about the exact order of pictures. I mean that for example we know for
sure that one picture will be before some another picture because
they differ by at least one parameter, which means that ORDER BY clause
has to include a list of parameters which has distinct values. For
example we order the pictures by date (when the picture was taken),
name and ID. Ordering by only date would not be enough because many
pictures could have same date. If the "name" field can be same for
many pictures with the same date, then we'll have to add something
more. I added ID because I assume it's the primary key in this database
table. In order by clause I always include all columns from some unique
constraint to make sure that the order is perfectly defined. In many
cases this means that I have to include primary key columns in order
by because in many cases it's the only unique constraint in the table.


> If I deleted a previous pic, then number
> 32 might now be in the 31st position unless I rename all my pictures
> everytime I remove one - and that seems like overkill.

If calculating the page number is difficult (our DBMS does not
allow you to perform this calculation and you have to do it in PHP),
then do the calculation only when it's really needed. Which means
that when a user is on some picture page and the page has to have
links to thumbpage and setpage, then do not calculate pagenumber for
those links, but include picture ID in the links. The thumbpage
and setpage script would have to be able to display proper page
when given page number and also when given picture ID. This way
the calculation is made only when the user clicks thumbpage or
setpage link. (In case of setpage it should also be able to calculate
page number based on thumbpage number to make the same mechanism
work when going back to setpage from some thumbpage.)


> $SESSION variables seem like the way to go since the user can't change the
> thumbs per page, only I can, and even if they could, it wouldn't be on the
> fly, they'd have to go to a 'settings' menu and start their browsing over
> again so the $SESSION problem mentioned won't be an issue for me.
>
> My problem at this point though is properly using $SESSION as I stated in a
> message parallel to yours in the reply tree.
>
> I've got a seperate thread started on clarifying $SESSION usage so I won't
> state it again here.

Yes, $_SESSION may be the solution. I saw your thread about it, but I'm
not able to help in this case.


Hilarion