Hi all,

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
worth 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 one page.

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 "Ruby 
on Rails: Spinoffs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to