views:

200

answers:

7

Is it possible to have JavaScript (specifically, JavaScript variables and their content) survive full HTTP requests? I'd like to 'cache' / persist information client-side across page changes, without having to use hidden form fields or anything HTML related at all.

Is this possible?

Edit: Let me add a use case for what I mean.

  1. Let's say I have a JavaScript array called arrayOfPersons which I loaded as part of page /HomePage, and now it contains 1,000 objects client-side.
  2. Now the user switches the page and loads an entirely new page /MyAccount into the browser
  3. My Goal: Still have the arrayOfPersons that I loaded on page /HomePage available after the user requested the entirely new page /MyAccount.

Hope that clarifies what I mean. Thank you!

A: 

A frameset would give you a place to persist your javascript, but full page load... I think not.

Cookies might also be useful for "persisting" data, but this isn't what you asked.

spender
+2  A: 

Found a useful one

JSOC: JavaScript Object Cache

The JSOC framework is a a pluggable, extensible, open source client-side caching framework for JavaScript.

JSOC offers Web developers a straightforward way to perform common caching techniques (add, replace, remove, flush, etc.) inside any JavaScript-enabled browser.

Since JSOC is a standalone JavaScript module, incorporating JSOC into a Web development project is a matter of including a script reference, and working with common caching methods. Low-level methods are contained in the JSOC JavaScript module so that developers can focus on the Web development task at hand.

rahul
I think that's a memory cache for a single page - it won't persist anything between pages as requested.
Nick
That suffers the same problem Alex is asking how to solve.
Crescent Fresh
A: 

if i understand you correctly, all you need is to add your own caching functions into onSubmit of all forms and onClick of all links, smth like:

var cachedpages;
$("A").onclick(function(){
    url = $(this).attr('href'); // maybe hash?
    if (cachedpages[url]) {
         // replacing all html
    } else {
         $.get(url, function(data){
              cachedpages[url] = data;
              // replacing all html
         });
    }
    return false;
});
valya
I've added some clarification :)
Alex
oh. i really have to improve my English skills :) try to tell users to install Gears and store your data there
valya
+3  A: 

Yes it is possible. Its a bit of a hack i used to maintain the page state(in client side) throughout the entire session.

Have a base page (like master), that never refreshes through out the session and it only got the iframe within it. And all your application pages will be loaded in to that frame..

Store your state info into that master page as JS objects. And you can access the master page (parent) javacript objects from your child page in a iframe. And it ll be maintained through the session in client side.

This is the simplest way. And it works pretty neat.

cheers

Ramesh Vel

Ramesh Vel
Did you ever encounter problems with this, e.g. browsers didn't like it, design issues, or anything like that?
Alex
No Alex.. We have never experienced any problems with this approach. Our application is designed for IE only. But am sure this approach should work with any browser, because we dont use any fancy technologies here.. we just let javascript objects reside in master page.
Ramesh Vel
The problem with this approach is that the browser's location bar will keep showing the "base page"'s URL, making it impossible for the average user to bookmark any of the pages he's actually viewing.
Michael Borgwardt
And the amount of data we persist here is pretty large, nearly all our application pages cosume this state object for their puprose and it works fine.
Ramesh Vel
Another problem is links from search engines. They will link to the actual page, not the master page. That means that the page shows without the master page, so they doesn't have the client state support.
Guffa
@Guffa, you are right.. this is not suitable for internet applications targets SEO.. its pretty suitable for applications that runs in enterprise servers and closed circuit...
Ramesh Vel
+2  A: 

Newer browsers support DOM storage which let you store arbitrary data that can persist between pages. You can also use a hidden Flash app to remember things. There are libraries like Dojo Storage which handle the detection for you, so you just save your data and it will use whatever is available.

It won't automatically save all your Javascript variables for the next page - you'll need to add an onunload handler to store what you want when the user leaves the page.

Nick
+1 Very interesting link!
Alex
+4  A: 

Just to add to Nick's answer, different browsers support the idea of persistent storage in one form or another. There have been a bunch of efforts to normalize these for all browsers over the last year.

Here's one library that wraps around HTML 5's DOM Storage, Microsoft's UserData, Session Cookies and window.name (using JSON serialization as window.name can only store strings).

Here's another that focuses on window.name only (which actually works in Opera 9+, IE6+, Firefox 1.5+, Safari [3 I think).

Here's a jQuery plugin that uses a .swf (flash) file to offer the most cross-browser support (although it does support native solutions if you configure it to do so). I can't vouch for it but it should be mentioned for this jQuery-lovin' community.

Crescent Fresh
Very nice and helpful links! +1
Alex
Nice links. Good find on the jQuery plugin - I'm a jQuery fan so I'd give that one a go personally.
Nick
A: 

One possibility is to use a frameset and keep the objects there, another to serialize them and persist the data via either of

window.name
document.cookie
location.search

document.cookie is the canonical way to store data between invocations of pages in the same domain and provides mechanisms to control access and lifetime.

If you use window.name, the data persists over the lifetime of the browser instance.

Using window.location is more tricky and you have to explicitly modify the links to send along the data (which can be easily done using event delegation).

Christoph