2005/9/11, David Binger :
>
> 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.


Almst the same here, I only use session for remembering search / page
number in simple CRUD-like pages when user goes back to records
listing after editing a record.

Speaking of urls, Routes rules :) http://routes.groovie.org/trac/

--
Ksenia