> From: Yuval Kogman [mailto:[EMAIL PROTECTED] > 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 _______________________________________________ List: [email protected] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
