On 9 Nov 2008, at 20:30, Robert Cummings wrote:
On Sun, 2008-11-09 at 20:16 +0000, Stut wrote:
On 9 Nov 2008, at 18:37, Robert Cummings wrote:
On Sun, 2008-11-09 at 18:22 +0000, 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.
Depends on the situation really. I'd really not restrict myself in
an
environment where there is sufficient possibility for which X
numbers
whose cumulative digits could easily break the 1024 byte lower bound
for
GET requests. How many digits are these IDs? How man can be chosen?
It's
not unreasonable to select pages of some kind of item. It would only
take 200 averaging 5 digits to break the limit. The solution here is
simple in both respects, and using sessions really doesn't strike me
as
using a sledgehammer.
I don't disagree, I was just pointing out that sessions as
implemented
by PHP are not the only answer to data storage between requests and
in
a lot of cases are overkill. It's a decision you have to base on the
requirements and expected future developments of a project.
I firmly believe the advice given on this list should provide choices
rather than dictate methods. There's always more than one way to do
something.
I absolutely agree, I certainly don't think what you proposed is in
any
way wrong, but *my* preference for this particular problem would
probably be to use the session. I avoid the session as much as
possible
since then you can't provide a link to someone via email to bring up
the
same context as you had, but in this case that seems an unlikely
scenario, whereas the possibility of accumulating many items is quite
likely given the items will be paged.
Agreed, but IMHO lack of URL-sharing is just one of many reasons to
avoid sessions if possible.
Taking further context though on my stream of responses... you did
say:
Seriously? You'd rather use sessions than explode, modify and
implode an array of numbers on each request?
This suggests you thought my particular opinion to be ludicrous ;) As
such, I felt inclined to more strongly defend my stance.
I should've explained the context of that reply. I was specifically
referring to your assertion that "sessions are easier to manage". They
are slightly easier than most alternatives for the developer, but they
can quickly become a nightmare for the sysadmin.
-Stut
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
