<!--Page Language="C#" AutoEventWireup="true"--><!--CTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dt--><!-- div.wikidoc pre { background-color: #ECECEC; border: dashed .1em #3E62A6; font-family: Consolas, "Courier New" ,Courier,Monospace; font-size: 1em; margin-top: 0; padding: .5em; padding-bottom: 1.5em; height: auto; overflow: auto; } --><form id="form1" accept-charset="UNKNOWN" enctype="application/x-www-form-urlencoded" method="get">
As a web developer I have often had to work with the session, cookie, query string and cache to persist data locally. But it has always struck me that there was no neat way of doing so. So I came up with this wrapper which is meant to provide a much simpler and unified model to work with. It is type safe and supports complex data types even when working with cookies and query strings, thanks to Json serialization which by the way has full support within javascript. Also a variable can seamlessly be based on more than one persistence type if need be.

Below is a sample code that creates an object to store and integer in a session under the key "counter":
  var count = new DynamicStore("counter");
The Value property is used as follows to manipulate the integer:
  count.Value = count.Value + 10;
Now to store the integer in a cookie the Sources.Cookie argument can be used as follows:
  var count = new DynamicStore("counter", Sources.Cookie);
And this is how the Sources enum is declared whereby Sources.Session is the default when not specified:
public enum Sources
{
        None = 0,
        QueryString = 1,
        Session = 2,
        PathBoundSession = 4,
        Cookie = 8,
        PathBoundCookie = 16,
        SessionBoundCookie = 32,
        UserBoundCookie = 64,
        Cache = 128,
        PathBoundCache = 256,
        SessionBoundCache = 512,
        UserBoundCache = 1024,
        BrowserBoundCache = 2048,
        FileCache = 4096,
        PathBoundFileCache = 8192,
        UserBoundFileCache = 16384,
        SessionBoundFileCache = 32768,
        BrowserBoundFileCache = 65536,
}
The key "counter" can be hardcoded in a custom class Keys to avoid typo errors:
  var count = new DynamicStore(Keys.Counter, Sources.Cookie);
This is a generic version of the above example:
  var count = new DynamicStore<int>(Keys.Counter, Sources.Cookie);
Complex types are also supported as shown here using a custom class Person:
  var person1 = new DynamicStore<Person>("person_1");
More than one source type can also be specified sequencially as follows in case the former type returns a null value:
  var person1 = new DynamicStore<Person>("person_1", Sources.Session, Sources.Cookie, Sources.Cache);
In the above example the object will first look for the specified key in the session. If this attempt fails then the request will turn to the next sources cookie and cache in the queue.

By default our object value is saved to all the targets in the source list(ie session, cookie and cache in our case). You can avoid writing to the cache, for example, by limiting the target types to the session and cookie as follows:
  var person1 = new DynamicStore<Person>("person_1", Targets.Session + Targets.Cookie, Sources.Session, Sources.Cookie, Sources.Cache);
Note that saving complex objects to the cookie and query string is achieved by using Json serialization.

Now there is yet another way to access keys, more especially those having a common prefix. Here is how:
  var persons = new DynamicStore<Person>("person");
 var person1 = persons[1].Value;
 var person2 = persons[2].Value;
Note that "_" is the default delimiter used to seperate the parent a.nd the child key. It is also the default key delimiter used with cookies since they inherently support parent/child keys.

Note that you can call the ToString() function on any object having a complex generic type to obtain its Json representation.

This wrapper brings a lot of flexibility but you should avoid saving more data to cookies and query strings than they can handle. A cookie will automatically clear itself when it grows beyond its size limit. To help overcome those issues an error will be thrown whenever the query string size grows beyond its 2048kb size limit and cookie compression has now been implemented.

More information on this project will be added with time if it gets enough traction from the community and meanwhile, of course, your suggestions, questions and critics are most welcome.
</form>

Last edited Sep 19, 2011 at 10:44 PM by ZiadJ, version 1

Comments

No comments yet.