Hi all, (I am reposting this from the spinoffs list by request from the only response received there)
It seems to me that as AJAX applications mature and become more popular, many Prototype deployments will require some sort of caching layer. Perhaps some would say that caching belongs outside of Prototype, however I believe that putting it inside deserves consideration for the following reasons: 1. More and more projects will require caching functionality 2. The functionality wouldn't require much code. 3. HTTP header values in server responses could potentially be useful (as in standard web apps) to control client-side cache expiration (see CacheableUpdater below). Furthermore I suspect that implementing caching externally as a wrapper for Prototype would preclude the use of these headers. Therefore I think extending the Prototype library with caching support is worthy of consideration. To illustrate, something like a couple of alternative methods to Ajax.Updater could be implemented... Ajax.SingleUpdater - Fetches the URL once, then returns the same content on subsequent calls with the same URL. Ajax.CacheableUpdater - Respects standard HTTP 'Expires' / 'Pragma' headers when deciding whether to re-issue an HTTP request or return the last content fetched. Thoughts? - Walter PS: AFAIK the list past posts only have one ruby code snippet related to caching, nothing language-agnostic at the Prototype/JS level... as it happens we use PHP (our app needs strong unicode support, including regexes.) PPS: For those interested, our usage scenario is as follows. The app we are currently developing a lot of input fields are both multilingual and of an arbitrary number. We are using dynamic, javascript-generated input field sets to provide an elegant UI solution, but have MANY such fieldsets on our pages. Therefore loading the (long) list of languages via Prototype only once, then re-using it, would be an excellent optimisation for a) initial page size b) UI responsiveness At present, with 'pure' Prototype Ajax.Updater re-issues the HTTP request each time an instance of a multilingual field is created. Sure, we could implement a once-off caching solution, but shouldn't this more generic problem be solved closer to home in Prototype? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~----------~----~----~----~------~----~------~--~---
