On 9/11/05, David Binger  wrote:
>
> On Sep 10, 2005, at 8:14 PM, Mike Orr wrote:
>
> > Here's a Quixote site that shows offshore oil spills and chemical
> > spills related to Hurricane Katrina.
> > http://www.incidentnews.gov/
>
> I like your site.
>
> I wonder if this trouble could be avoided by using a different url
> organization.
> Why not make the link to
> http://www.incidentnews.gov/1/search_entries_action?category=6
> be, instead, a link to
> http://www.incidentnews.gov/1/entries?category=6
> or
> http://www.incidentnews.gov/1/category/6/

I may have to go to that.  But it seems like kludging something that
should just work in the first place.  "/1" is in that format, but it's
a specific record, not a "search".  I consider 'category' to be "just
a criteria", and there will be more elaborate searches later.

I'll see if 'response.cache = -1' helps.  The source say this works
better than 0 for some browsers.  Which ones?  The RFC doesn't mention
-1 at all, but says especially 0 should be supported.

> Is it really worth it to cache the entries for a category on the
> session?
> It seems more reliable to do the searching and displaying in the same
> request.  Is that too slow to be practical?

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.