On Sep 11, 2005, at 11:06 AM, Mike Orr wrote:
> Sometimes there will be hundreds of entries so they need to be paged.
> I found it too unworkable to use the same URL for both searching and
> paging, because you have to juggle the input params for so many cases:
>
> - criteria present, new search.
> - 'page' present, go to that page.  Get criteria from session.
> - nothing present, show same page again.  Or do a new search?
> - oops, they pressed the Back button.  Which one do we do?  What if
> the session and params are inconsistent?
>
> Any table that doesn't need to be paged, I regenerate each time.  I
> tried doing that with the paged tables but it seemed more trouble than
> it's worth.  The tradeoff is, I have to check every result record
> before displaying it, in case it's been deleted in the meantime.  If
> so I just skip it.

The pattern we've used is to treat every request as a new search,
with the query string holding the criteria and the page number.
(like http://www.incidentnews.gov/1/?category="whatever"&page=3
The default page number is 1, the default criteria is empty.
Nothing is cached.  The GET requests don't change the server state,
so it doesn't matter if they press the back button.
Maybe this pattern would be useful in your situation.