[Catalyst] query once per session?

[Michael Higgins]

> From: Yuval Kogman [mailto:nothingmuch at woobling.org] 
> Sent: Thursday, April 26, 2007 3:04 PM
> 
> On Thu, Apr 26, 2007 at 14:35:09 -0700, Michael Higgins wrote:
> > Hello,
> > 
> > I'm wondering how I can get a query (that becomes a 
> drop-down list for 
> > a form field) set to execute only once and return the data from the 
> > client side, or at least from memory, until the session ends.
> > 
> > I've set something up to filter results based on selection from a 
> > form, but getting the list each and every time is too lengthy a 
> > process for a table only updated once a day.
> > 
> > I've tried using Plugin::Catalyst::Cache, but the docs 
> leave me clueless.
> 
> I've invested quite a bit of time writing and auditing the 
> docs with others, so I don't know if I can wholeheartedly 
> apologize for that
> ;-) Please come to #catalyst and we'll see if we can give you 
> a small shove in the right direction (ping nothingmuch).
> 

Ah. Well, I got something working, I believe, using Cache::FileCache...
which is marginally faster than retreieving it every time. Probably, I need
a different cache method.

> Using a serverside cache will let you have finer control over 
> the time to live (for example just till the next scheduled 
> update of the table), and will also allow you to share 
> results between users easily. It should work well in 
> conjunction with the other options, too.
> 

It seems the most expensive part might be moving the data to the client.
Maybe I could I speed that up somehow? 

> As for pure client side -- look into the javascript cookie 
> api.  You can store JSON in a cookie from the server, or 
> embed it in the JS and have the JS load it. Either way it 
> should be a simple eval() once you read the cookie value. 
> This will probably waste the least bandwidth of the three 
> options, but will be the most PITA to write.
> Sharing results between users will be tricker here, though.
> 
> Yet another option is to simply add caching headers to a JSON feed:
> 
> 	/yourapp/feeds/the_drop_down_params/options_here
> 
> and then set that up with proper expiry headers.
> 
> Note that i didn't specify ?options_here - you should be 
> careful with query params since cache servers like squid will 
> automatically not cache anything with query params. this is 
> the easiest to implement in javascript (The feed URI thing is 
> easy) and offloads the caching details to the client, but is 
> probably the least performant of the three options.
> 
> 
> If your javascript-fu is low, i'd stick with just serverside cache.
> That will give you a nice up front boost. If the data set is 
> large enough that caching on the client side is really worth 
> it, i'd start with the json feed option, and then look into 
> JS cookies (much tricker to work around the 4kb limit here).

Or, I think you mentioned just coding it into a javascript and having that
load into the page when requested. I like this idea. This data can persist
for a while. I could have a link to explicitly refresh the list, no? This is
for internal use, basically. Clients have this number hard-coded in their
session.

My javascript-fu is non-existing, but I've done things I didn't know how to
do before, albeit with mixed results... Since I'm a one-man department, any
highly-recommended free resources folks could point to for honing one's
javascript-fu would be helpful. ;-)

Thanks a bunch for all the pointers.

Cheers,

-- 
Michael Higgins