Managing Persistent Data In Your Web Applications Using DOM Storage

The 90’s saw many inovations in the web, but not much changed in the way of client side storage. Javascript and cookies were the way to keep user data saved in the browser.

Recently various techniques for storing and retrieving data have emerged. There are so many different ways in fact that we need to answer some questions to determine the best solution for persisting data between requests.

We have to ask who needs the data ? How long does the data need to be persisted?  And how large is the set of data?

Persistence Method Who Needs the Data? For How Long? How Much Data?
Application All users Until the next application restart Can be almost any size—it will only be stored once
Cookie One user As short as desired, or for months or even years if the user doesn’t delete their cookies Minimal, simple data
Form Post One user For the next request (can be reused across many requests) Virtually any size—the data is sent back and forth with every page
QueryString One user or one group of users For the next request (can be reused across many requests) Minimal, simple data
Session One user As long as the user is active, plus a timeout period (typically 20 minutes) Can be almost any size, but should be minimized since every user has their own separate session store
Cache All users or a subset of users As long or as short as needed Can be used for large or small, simple or complex data
Context One user This request only Can hold large objects, but typically does not since it is often used for every request
ViewState One user One Web form Minimal; as with Form Post, this data is sent back and forth with every page
Config file All users Until the configuration file is updated Can hold a lot of data; usually organized as many small strings or XML structures

Application

Let’s set the object use criteria by answering the state questions I asked earlier. Who needs this data? All users need access to it. How long does this data need to be persisted? It has to live forever, or for the life of the application. How large is this data? It can be almost any size—only one copy of the data will exist at any given time.
In classic ASP, the Application object provided a great place to store frequently used pieces of data that changed infrequently, such as the contents of menus or other reference data. While the Application object is still available as a data container in ASP.NET, other objects are generally better suited for the kinds of data that would have been stored in the Application collection of a classic ASP application.
Cookies

Cookies are handy when a particular user needs a specific piece of data, and it needs to be persisted for a variable period of time. It can be as brief as the life of the browser window, or as long as months or even years. As far as size goes, cookies are very small. Cookies can be as small as only a few bytes of data, and since they are passed with every browser request, their contents should be kept as small as possible.
Security NOTE : The best way to secure sensitive state that should not be viewed or modified by a hostile user is to store that state on the server. If sensitive data must be sent to the client, it should be encrypted beforehand, regardless of the storage mechanism employed.
Form Post / Hidden Form Field

Form data is needed by a particular user, and it must be persisted for any period from a single request to the life of the application. The data can be virtually any size; it’s sent back and forth over the network with each form post. This requires the data to be sent back and for to each other using Submit buttons, or saved on the client machine with cookies.  This was a classic technique that is not recommended anymore.
QueryString

The data stored in the QueryString object is used by the individual user. Its lifetime can be as brief as a single request, or as long as the user continues to use the application (if architected appropriately). This data is typically less than 1KB. Data in a QueryString is passed in the URL and is visible to the user, so as you might guess, sensitive data or data that can be used to control the application should be encrypted when using this technique.
That said, the QueryString is a great way to send information between Web forms in ASP.NET. For example, if you have a DataGrid with a list of products, and a hyperlink in the grid that goes to a product detail page, it would be an ideal use of the QueryString to include the product ID in the QueryString of the link to the product details page (for example, productdetails.aspx?id=4). Another advantage of using QueryStrings is that the state of the page is contained in the URL. This means that a user can put a page in their Favorites folder in its generated form when it’s created with a QueryString. When they return to it as a favorite, it will be the same as when they actually made it a favorite. Obviously, this only works if the page doesn’t rely on any state outside the QueryString and nothing else changes.
Along with sensitive data, any variable that you don’t want the user to be able to manipulate should be avoided here (unless encryption is used to remove human-readability). Also, keep in mind that characters that are not valid in a URL must be encoded using Server.UrlEncode, as Figure 7 shows. When dealing with a single ASP.NET page, ViewState is a better choice than QueryString for maintaining state. For long-term data storage, Cookie, Session, or Cache are more appropriate data containers than QueryStrings.

Session

Session data is specific to a particular user. It lives for as long as the user continues to makes requests plus some period of time afterward (typically 20 minutes). The Session object can hold large or small amounts of data, but total storage should be kept minimal if the application is intended to scale to hundreds of users or more.
Using the Session object is easy and its syntax is identical to classic ASP. However, the Session object is one of the less efficient ways of storing user data, since it is held in memory for some time even after the user has stopped using the application. This can have serious effects on scalability for a very busy site.
For small amounts of data, the Session object can be a perfectly valid place to store user-specific data that needs to persist only for the duration of the user’s current session.
This sounds like the way to go for my progress reporting application. So, lets dive into a demo and see how we can save some data in session object.

Here is some sample session variable code: Methods

Create session variable and set it:

Session(“varName”) = varValue

 

Get on page:

newVar = Sesssion(“varName”)

 

Clear session variable:

Session(“varName”) = “” OR

Session.Contents.Remove(“varName”)

Clear out session when done:

Session.Contents.RemoveAll()    OR

Session.Abandon

I would combine the two to ensure that pesky session data is gone.My logout script is :

Session.Contents.RemoveAll()
Session.Abandon
Response.Redirect(“default.asp”)

The session object has the onStart and OnEnd events and the SessionID and Timeout properties

 

A session ends if a user has not requested or refreshed a page in the application for a specified period. By default, this is 20 minutes. They could need longer for filling out these forms.

If you want to set a timeout interval that is shorter or longer than the default, use the Timeoutproperty.

Session.Timeout=5 gives the session 5 minutes of inactivity. I think you would want a few hours at least.

 

 

Here is the best resources for asp dev http://www.w3schools.com/asp/asp_sessions.asp

http://www.tizag.com/aspTutorial/aspSession.php

This is a summary of a microsoft developer network article. that was updated in 2005.

 

 

Now lets get into the new technology

Here is my personal test file http://itwebdev.mv.skagit.edu/don/stuff/dom%20storage/domstorage.html

DOM storage, also called Web Storage is comprable to cookies. However, web storage offers more control of  how the information is stored and accesed by each window.

This technique also offers a lot more storage space, and quite different functionality than cookies.

 

The web storage scripting objects have been drafted into the HTML 5 working draft specifications, and have gathered major vendor support.

window.sessionStorage
Session storage is designed for scenarios where the user is carrying out a single transaction. The sessionStorage attribute of the window object maintains key/value pairs for all pages loaded during the lifetime of a single tab (for the duration of the top-level browsing context). For example, a page might have a check box that the user selects to indicate that he wants insurance. A later page could then check, from script, whether the user had selected the check box.

The Storage object supports expando properties (‘insurance’ in the preceding example). If the property name does not exist, a key/value pair is automatically created to hold it. Note that key/value pairs are always stored as strings. Different data types such as numbers, Boolean values, and structured data must be converted to strings before persisting to a storage area.

After a value has been saved to sessionStorage, it can be retrieved by script running in another page in the same context. When another document is loaded,sessionStorage is initialized from memory for same-origin URLs

Note  Although it is allowed by the HTML5 (Working Draft), Internet Explorer 8 does not resume sessionStorage after browser crash recovery.

 

window.localStorage

The local storage mechanism spans multiple windows and persists beyond the current session. The localStorage attribute provides persistent storage areas for domains. It allows Web applications to store nearly 10 MB of user data, such as entire documents or a user’s mailbox, on the client for performance reasons.

here is the msdn article that this blog post sumarrizes http://msdn.microsoft.com/en-us/library/cc197062(v=vs.85).aspx

 

 

Leave a Reply