> From: Ken Y. Clark [mailto:[EMAIL PROTECTED]] > Sent: 12 June 2002 15:39
> I've munged the query results in Perl and a couple template > packages to make each link contain everything necessary to > perform the query again (including every parameter from the > original request) and putting in the appropriate "limit_start" > number... Using sessions and a query_id is a shortcut for this, instead of stating all the complex parameters again, you just issue an id and put that into the link. An advantage of the session/id is that you end up with stateful query instances, and can remember [at least for a short period!] the total number of items, so that you can say 'Results 1 to 10 of 34,566' without having to count all results every time. This is also useful if you want users to be able to jump to a LAST page, as you can for example calc the starting point for limit statement easily. One disadvantage is that you cannot link to the query result pages, as you will no doubt expire the query sessions eventually. By putting all the params in the link, Ken's way lets the users link to the results, remember them in their favourites etc. Another possible feature is to allow the link to override any of the current query parameters, so to do a DB resort, you can say something like <A HREF=/query?query_id=12345&order=colour>Sort by Colour</A> and the order param is not lost in amongst lots of other params. Obviously changes to the where clause, ordering etc may invalidate current row / page remembered values. Further variations are readily available. You can create persistent queries, rather than session queries, store the params in the DB and let your users have their very own private or shareable searches. If you use the optional param overide approach, you can store the params once, and then the options as a separate query that refers to the underlying query. When users add columns or other bits to the underlying, all child searches will respect the change. Regards Jeff
