Interesting idea, although I''d personally prefer to see this as a
wrapper and packaged neatly in an addon library. However, post this over
at the Prototype Core group, that is where all of the discussion
relating to changes to Prototype are discussed and most if not all of
the core team members read it somewhat regularly.
http://groups.google.com/group/prototype-core
Colin
Walter Stanish wrote:> 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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---