Roger that -- so: include the search params in the links, and recreate the
recordset each time via ...->search({},{}). Sounds reasonable.Off to the salt mines... On Sun, Sep 16, 2012 at 10:07 AM, Bill Moseley <mose...@hank.org> wrote: > > > On Sat, Sep 15, 2012 at 7:06 PM, will trillich < > will.trill...@serensoft.com> wrote: > >> Hi Francisco -- >> >> I'm not talking about paginating a resultset, I'm talking about returning >> to a previously-established resultset on some future HTTP request. Here's >> the scenario: >> > > You are asking just how to display multiple pages of search results? > > >> >> 12:01 Bob submits search form for "Chicago between 1-Apr-2012 and >> 30-Apr-2012" >> > > Use a GET, not a POST. > > I'm Ignoring timezones, but you should not. > > > http://example.com/event_list?city=Chicago&after=2012-04-01&before=2012-04-30&rows=100&page=1<http://example.com/event_list?city=Chicago&between=2012-04-01:2012-04-30&rows=100&page=1> > > >> >> 12:02 Bob sees first page of results, records 1-100 >> >> 12:03 Bob clicks to see second page of results, records 101-200 >> <= how do we re-establish the recordset here, from the original search >> form at 12:01? >> > > > http://example.com/event_list?city=Chicago&after=2012-04-01&before=2012-04-30&rows=100&page=<http://example.com/event_list?city=Chicago&between=2012-04-01:2012-04-30&rows=100&page=1> > 2 > > >> >> 12:04 Bob clicks thru to see detail on record 135 >> >> 12:05 Bob clicks breadcrumbs to "return to search" >> <= how do we re-establish the recordset here, from the original search >> form at 12:01? >> > > > http://example.com/event_list?city=Chicago&after=2012-04-01&before=2012-04-30&rows=100&page=1<http://example.com/event_list?city=Chicago&between=2012-04-01:2012-04-30&rows=100&page=1> > > > All independent requests -- someone may bookmark page 2 and go back there > directly. > > > Then (later) think about caching. That depends on usage, your database > load, your SLA, your traffic, load, etc. You could fetch the entire result > list on the first request and cache, for example, or you could instead > cache the entire page (with a separate page cache layer). > > Use a cache, not the session, for caching. There's nothing here related > to the session unless you wan to display something like "recent searches" > to show on all pages -- and even that might be better in the cache keyed by > user's ID if users are required to log in. > > > >> >> >> >> On Sat, Sep 15, 2012 at 2:55 PM, Francisco Obispo <fobi...@isc.org>wrote: >> >>> Some databases provide means to return a specific set of records, and >>> even an offset, >>> >>> In DBIx::Class, when you search, you can actually specify the "page" as >>> an option [1], >>> >>> if you're not querying against a database, you might want to use >>> something like Memcached or the like to store your resultset and paginate >>> accordingly. >>> >>> >>> >>> >>> [1] >>> http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class/ResultSet.pm#ATTRIBUTES >>> >>> >>> On Sep 15, 2012, at 11:41 AM, will trillich <will.trill...@serensoft.com> >>> wrote: >>> >>> > User enters some search parameters (location, date-range, etc). Gets >>> 500 results which we paginate. Once the user pages to the item of interest, >>> he/she can then click thru to edit or see more detail. >>> > >>> > It'd be nice to have 'breadcrumbs' that take the user back to that >>> page of that search. >>> > >>> > What's the recommended way of doing that? >>> > >>> > A) stash the whole recordset into the session (can you even >>> serialize/deserialize a recordset object?) >>> > >>> > B) stash the search params and page-no and page-size and recreate the >>> recordset each time >>> > >>> > C) ...something else? >>> > >>> > >>> > >>> > -- >>> > Will Trillich :: 812.454.6431 >>> > >>> > “Waiting for perfect is never as smart as making progress.” -- Seth >>> Godin >>> > _______________________________________________ >>> > List: Catalyst@lists.scsys.co.uk >>> > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst >>> > Searchable archive: >>> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ >>> > Dev site: http://dev.catalyst.perl.org/ >>> >>> Francisco Obispo >>> email: fobi...@isc.org >>> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC >>> PGP KeyID = B38DB1BE >>> >>> >>> _______________________________________________ >>> List: Catalyst@lists.scsys.co.uk >>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst >>> Searchable archive: >>> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ >>> Dev site: http://dev.catalyst.perl.org/ >>> >> >> >> >> -- >> Will Trillich :: 812.454.6431 >> >> “Waiting for perfect is never as smart as making progress.” -- Seth Godin >> >> _______________________________________________ >> List: Catalyst@lists.scsys.co.uk >> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst >> Searchable archive: >> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ >> Dev site: http://dev.catalyst.perl.org/ >> >> > > > -- > Bill Moseley > mose...@hank.org > > _______________________________________________ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > > -- Will Trillich :: 812.454.6431 “Waiting for perfect is never as smart as making progress.” -- Seth Godin
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
