Home/ Questions/Q 529659
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T09:06:54+00:00

I build portable HTML/Javscript prototypes, which are intended to be Zipped up and shared

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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).

    • 0