NYCPHP Meetup

[Kenneth Dombrowski]

On Mon, Sep 02, 2002 at 10:28:15PM -0400, janis p gale wrote:
> if i'm following correctly...  you're suggesting that instead of
> propagating the result set id list to a GET/url variable or in a
> cookie or in a temporary database row...  that you do a silent
> POST with the id's in a hidden field...
> 
> this presents the problem of having to create a form on each
> of the result pages...  so, say, the page-turning links couldn't
> just be variations on the result url, they'd have to be javascript
> links that would POST the form containing the hidden field...
> essentially turning every page-turn into a simulated form POST,
> not a simpler click on an actual href...  thus, removing the
> possibility of the user being able to bookmark the search result.
> 

Yes, you're following correctly, every page turn would be a POST
request, though there's no need for JavaScript that I can see.
'Next'/'Last' links just need to be in the form of good old-fashioned
button or image elements. Personally I consider the maintenance of a 
form to be no more complicated than working with the query string. 

But I was writing in response to Joseph Annino: 

"I'm thinking a way to kill two birds with one stone is to create a
unique 'search session id' and place it in hidden fields and urls ...

which seemed to introduce hidden fields as a means of tracking a 'search
session id' for a lookup in a temporary row, which seemed redundant if
the hidden form is already there. It's an approach I'm trying out
recently in a project where until now I've just re-run the query on
every page, and it happens to be well suited to my data. If users leave
the 2 level deep result set pages they lose the results (though if
cookies are accepted the search field values are remembered)

If you want particular search results to be bookmarkable obviously it
won't work. In that case you can't rely on temporary database rows
either, but must put everything in the query string.

It was just a thought,
Ken