Best practice for saving and recalling selected checkboxes on an asp.net page

Question

I am looking for ideas on the best way to persist an array of values from one web session to the next. I will be populating a Checkbox list and would like to persist the last set of selected checkboxes to the next session. (this is meant to save time for the user since they will likely always select the same subset of checkboxes.)

I will be iterating through the checkbox list and putting the selected values into an arraylist.

Where would be a good place to presist this set of data? I looked at storing the object to database or possibly an XML file on the server. I also considered pushing the data to the web.config but would like to avoid an application restart.

Any opinions or suggestions?

TIA

J

Answer 1

The way I did it was to persist the checkboxes into a boolean column in my database. The checkboxes are bound to the boolean column, so when the page is opened again, the checkboxes contain the state that was saved.

Answer 2

What about storing them in a cookie? Create an object that consists of booleans and serialize to the cookie:

class Checks() {
    public value1( get; set; )
    public value2( get; set; )
    public value3( get; set; )
    ...
    public valueN( get; set; )
}

Answer 3

I am a bit confused on this question , you mentioned WebSessions and even thought to persist the settings in Webconfig, but how many sessions would you persist and how would you clean up the unused sessions, leave a part the Web.config consider any XML file , the basic questions I have

• Are the settings(Checkbox selections) @ Session Level or the Application Level ?
• What is the persistence time period?
• Is that data required on Server site for some other processing OR it's fine if it's on the client side.
• Does users have unique identification Users Uniquely??

If the requirement seeks quick solution and shall not grow,

1. In case of client side persistence use Cookies and on the Sever side have an custom object to represent the state read from the Cookie
2. In case of Server side persistence use an XML file and schema which helps identifying the unique identification of the User as Key and load the settings in a Custom class.

If the requirement seeks longterm solution and would grow in the future then use ASP.NET Profiles and use the available profile providers (SQL SERVER) if suitable or Implementing your own Profile Provider.

Answer 4

If you already are using a database for your application, I would be inclined to save the state of the check boxes in the database. Reason is because databases are already equipped to handle multiple instances of people accessing the application and concurrency issues are easier to handle. Not to mention more scalable.

I would create a table that has enough columns to capture all the information about each check box. For Example:

CREATE TABLE [CheckBoxStatus] (
[CheckBoxID] nvarchar(50),
[bool] bit NULL DEFAULT 0,
[SessionID] nvarchar(50));

On load of your page, you can interate through all of the check-boxes that are in your page, querying for their ID's inside this table. If there is no record of it, it means no one has selected the checkbox yet. If there is, then load the boolean checked status and update the checkbox on the page.

Same goes if you save, just insert Boolean values with the corresponding checkboxID and SessionID.

This should also work if your checkboxID's are created dynamically somehow. You only have to be careful that whatever generates your checkboxID's to be sure that it always generates the same ID for a particular kind of a checkbox.

So, if it is something like "Red Car" then every where that "Red Car" is displayed in the same context, the same ID needs to be generated.

Answer 5

There are really only two ways to do what you are talking about.

1. Have a variable at the application level which stores this information. Downside is that it gets cleared whenever the web app recycles.

2. Store it in a database table. Downside is that it requires a database call to get the data.

Allowing the site to write to the web.config is bad because it's a potential security risk. Same goes for allowing the site to write anything to disk. Sometimes we can't avoid it (file uploads), but we can at least contain it to non-executable areas.

Personally, for a site wide semi-permanent item I'd go with a combination of the two. I'd store it in a database table, but cache the results of the db call in an application level variable.

If my backend was sql 2005 or 2008, I might even take it a step further and use the SqlCacheDependency object so that the cache get's invalidated as soon as an update occurs on that db table.