views:

210

answers:

4

Hi

I build portable HTML/Javscript prototypes, which are intended to be Zipped up and shared via email/sharepoint. The key word here is 'portable' - no server is required to run these prorotypes - just a javascript enabled browser. And there is no database.

Some of the prototypes require that I persist data (just to show off potential functionality). I do this currently by using cookies. This seems to work fine for Firefox, Chrome, etc, but Internet Explorer appears to work differently.

Once the maximum size of 4096 bytes for all cookies from a domain is hit in IE6 and 7 (I haven't tested 8 yet) the cookies stop working. Once this limit is hit, then even reading from the cookie appears to stop happening and the prototype breaks.

Are there any other ways that I can persist data without having to use a server and a database?

Any ideas would be greatly appreciated.

+1  A: 

Although not widely available at the moment, there is HTML5 webstorage/localstorage.

jldupont
Unfortunately, the solution needs to be avaiable for all mainstream browsers. I can't force clients to use a specific or upgrade to a latest browser.
Sniffer
@Sniffer: I understand your position. Cheers.
jldupont
+4  A: 

store the data in a hidden field (or even multiple ones if needed).

Wrap the code that you use to read from the cookiees into a class/function in a separate file, and then you can easily swap the files out for live/sample instances--potentially as easily as commenting out one line, and un-commenting out the other.

EDIT DUE TO REQUEST IN COMMENT: This will work across multiple pages, provided that you push the data in the Hidden Fields across the multiple pages. If you don't wish to do POSTS from one page to the next, then you can wrap the page(s) into a frame and then have the Hidden Fields be located in a frame element that is not displayed (in this scenario, the fields don't technically need to be hidden ones).

What this is, is the page that is accessed has a FRAME tag, that points to two different pages. The first page is your application itself, and that takes up all the visible real estate. The second page is just a page which will hold one ore more controls that will retain the data, and this second page is not visible (to the user) at all. Since these pages are all part of the same "domain' then it's an easy matter for the frame child to talk to one of its siblings and read/write data to the hidden page's fields.

And the way that this gets around the cookie limit is that a text entry field is technically only limited by the memory on the computer and the timeout of the network throughput. For example, I've seen a hidden field with 20MB worth of data in it before (think the evilest of evil ViewStates).

Stephen Wrighton
Hi Stephen. Thanks for the reply. I'm struggling to get my head around this. Can you expand on this a little? Will this work across multiple pages, and how does this get around the cookie limit problem?
Sniffer
I like it! Thanks for clarifying. I don't normally use frames, but in this instance it makes sense (that is until HTML 5 gets a wider audience). It's only for prototyping after all. Thanks again.
Sniffer
+3  A: 

Check out YUI Storage.

Chris
Interesting. I'll look into this, although I generally use the jQuery library, so would prefer to use a jQuery version of this (if there is one).
Sniffer
Looks like there are some jQuery options. Not sure how mature they are. http://stackoverflow.com/questions/791412/offline-data-storage-access-using-jquery
Chris
+2  A: 

Dojo Storage will allow you to save up to 100k

Adam Crossland
Interesting. I'll look into this, although I generally use the jQuery library, so would prefer to use a jQuery version of this (if there is one).
Sniffer
If there isn't a jQuery version, you should be able to use just a sub-set of Dojo to get the Storage functionality. You should be able to continue using jQuery for most of your programming.Caveat emptor: I have never personally mixed jQuery and Dojo in the same application.
Adam Crossland