O/H Robert Cummings ??????:
On Sun, 2008-11-09 at 12:39 -0600, Micah Gersten wrote:
Robert Cummings wrote:
On Sun, 2008-11-09 at 12:26 -0600, Micah Gersten wrote:
Stut wrote:
On 9 Nov 2008, at 18:14, Robert Cummings wrote:
On Sun, 2008-11-09 at 18:00 +0000, Stut wrote:
On 9 Nov 2008, at 07:16, Robert Cummings wrote:
On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:
I've got a question/issue that I want to bounce off the list.
I have a list that extends over multiple pages. there might be 200
items,
and i don't want to have the items listed on the same page as it
would be
too long. i can break the list up, so i can have it be displayed over
multiple pages. however, i want the user to select different items
from the
list. given that the selected items might be over different pages,
what's
the best way of keeping a running track of the items that have been
selected??
I could have each page be a form, and do a post/get where i then
keep track
of the selected items from page to page, but that would appear to
get ugly.
i'm looking for pointers to other sites/code that might have already
implemented this kind of scenario.
thoughts/pointers would be appreciated...
Accumulate them in the session. When done, and before final action you
could let them view a summary of selected items and allow deletion of
any entries they don't want.
Unless they're likely to select hundreds of items I'd either go with a
persisted GET var or a cookie. No need to drag server-side storage
into this.
Well he did say he had multiple pages. Maybe he's only displaying 5 per
page though. Still, sessions are easier to manage than GET vars since
you don't need to append them to every form action URL to accumulate
them. Session is managed transparently by PHP in most cases an amounts
to the approximate overhead of an include.
Seriously? You'd rather use sessions than explode, modify and implode
an array of numbers on each request? You really see that as a valuable
developer time-saver?
The mind boggles, but as I've said before and probably will again it's
always a personal choice, I'm just suggesting alternatives.
-Stut
Also, by storing the information server side, there is less of a chance
of the user tampering with the data. Storing stuff in the session also
saves on network bandwidth of sending and retrieving the data with each
request.
Nah, the problem is the same. Tamper with the GET data or tamper with
the POST date before it goes into the session. Need to check the
incoming data regardless.
Cheers,
Rob.
Yes, but once it's in the session, it should be ok.
True, but the same possibility of tampering existed with the POST data.
Therefore the chance of tampering is the same.
Cheers,
Rob.
Not true because if the data are stored in the cookie every time that
the cookie is accessed the data are passing from the client to the
server. This adds further network traffic and gives the client the
chance to interfere with the cookie's data. So I think that the server
side storage (sessions) is safer because you check once, then store and
use as needed.
On the other hand sessions give bigger load to the web server.So
another solution could be to encrypt the cookie's data if that is the
way that suits you better in order to make things more secure...
----
Thodoris
