Re: [Catalyst] Best-practices question: caching a search

2012-09-16 Thread Bill Moseley
On Sat, Sep 15, 2012 at 7:06 PM, will trillich
will.trill...@serensoft.comwrote:

 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=Chicagoafter=2012-04-01before=2012-04-30rows=100page=1http://example.com/event_list?city=Chicagobetween=2012-04-01:2012-04-30rows=100page=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=Chicagoafter=2012-04-01before=2012-04-30rows=100page=http://example.com/event_list?city=Chicagobetween=2012-04-01:2012-04-30rows=100page=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=Chicagoafter=2012-04-01before=2012-04-30rows=100page=1http://example.com/event_list?city=Chicagobetween=2012-04-01:2012-04-30rows=100page=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/


Re: [Catalyst] Best-practices question: caching a search

2012-09-16 Thread will trillich
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=Chicagoafter=2012-04-01before=2012-04-30rows=100page=1http://example.com/event_list?city=Chicagobetween=2012-04-01:2012-04-30rows=100page=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=Chicagoafter=2012-04-01before=2012-04-30rows=100page=http://example.com/event_list?city=Chicagobetween=2012-04-01:2012-04-30rows=100page=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=Chicagoafter=2012-04-01before=2012-04-30rows=100page=1http://example.com/event_list?city=Chicagobetween=2012-04-01:2012-04-30rows=100page=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.orgwrote:

 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 :: 

Re: [Catalyst] Best-practices question: caching a search

2012-09-15 Thread Francisco Obispo
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/


Re: [Catalyst] Best-practices question: caching a search

2012-09-15 Thread will trillich
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:

12:01 Bob submits search form for Chicago between 1-Apr-2012 and
30-Apr-2012

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?

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?



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/


Re: [Catalyst] Best-practices question: caching a search

2012-09-15 Thread Rippl, Steve
I've used temporary tables for large search results I've needed to get back
to quickly and didn't want to rebuild from scratch...



On Sat, Sep 15, 2012 at 7:06 PM, will trillich
will.trill...@serensoft.comwrote:

 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:

 12:01 Bob submits search form for Chicago between 1-Apr-2012 and
 30-Apr-2012

 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?

 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?



 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/




-- 
Steve Rippl
Technology Director
Woodland Public Schools
360 841 2730
___
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/


Re: [Catalyst] Best-practices question: caching a search

2012-09-15 Thread will trillich
Steve --

Does that work when someone starts a search and then goes to lunch and
comes back the next day to click next? Do you key it to the session ID
somehow?



On Sat, Sep 15, 2012 at 9:21 PM, Rippl, Steve rip...@woodlandschools.orgwrote:

 I've used temporary tables for large search results I've needed to get
 back to quickly and didn't want to rebuild from scratch...



 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:

 12:01 Bob submits search form for Chicago between 1-Apr-2012 and
 30-Apr-2012

 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?

 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?



 On Sat, Sep 15, 2012 at 2:55 PM, Francisco Obispo fobi...@isc.orgwrote:

 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/




 --
 Steve Rippl
 Technology Director
 Woodland Public Schools
 360 841 2730

 ___
 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/


Re: [Catalyst] Best-practices question: caching a search

2012-09-15 Thread Rippl, Steve
To be honest this was on a low use internal app, and a new search would
trigger cycling the temp table.  I just threw this out there, but sure, you
could key it by session or perhaps have multiple temp tables depending on
traffic, and I'm sure you'd have to clean them up after some period,
again depending on traffic and capacity.

I don't know if this is best practice, I just found it useful for
navigating back and forth to a large search resultset...



On Sat, Sep 15, 2012 at 7:23 PM, will trillich
will.trill...@serensoft.comwrote:

 Steve --

 Does that work when someone starts a search and then goes to lunch and
 comes back the next day to click next? Do you key it to the session ID
 somehow?



 On Sat, Sep 15, 2012 at 9:21 PM, Rippl, Steve 
 rip...@woodlandschools.orgwrote:

 I've used temporary tables for large search results I've needed to get
 back to quickly and didn't want to rebuild from scratch...



 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:

 12:01 Bob submits search form for Chicago between 1-Apr-2012 and
 30-Apr-2012

 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?

 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?



 On Sat, Sep 15, 2012 at 2:55 PM, Francisco Obispo fobi...@isc.orgwrote:

 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/




 --
 Steve Rippl
 Technology Director
 Woodland Public Schools
 360 841 2730

 ___
 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/




-- 
Steve Rippl
Technology Director
Woodland Public Schools
360 841 2730
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable