ASP.Net View State. The extent of my knowledge up until this week consisted of:
- It a base64 encoded string that exists in a hidden field in the page
There is apparently significantly more to this beast than that. I’m not going to re-hash it here, as there are some really good articles on it already. I highly recommend this article in particular. When combined with the MSDN ASP.Net Page Object help it gives an excellent picture of exactly where view state sits in the scheme of a web page, and it’s intented use. Lets go with an example of why you’d use it. I have a repeater control. In the repeater list, I have check boxes for the rows, so that the users can group items for actioning. I can group items, and all is well, until I attempt to sort the list. As soon as I post back, my checks are all lost! Why?
Well, the most likely cause is that I’m binding my data to the repeater in, or after the page load.
The issue here lies in when the view state is loaded into the state bag. If you take a look at the two articles I’ve referenced above you’ll get a more in depth discussion of this, but the short answer is to move the loading and binding of data back into the init page method. What this does is ensures all the controls that the repeater creates (in my case – the check boxes) are all in the control tree before the view state is loaded.
The reason for the second one being an issue is that even though I’m now binding in the init method, is that I’m also rebinding after I do the sort. This causes the view state that I had before to no longer be applicable. The answer here? Some custom view state manipulation. In this example, what we can do is ensure that during the databinding, the check box for each row is given a meaningful id – I used the Id of the item I was binding to. Then, when the check box is checked, add an item to the view state using the id of the check box for the key (view state is a dictionary) and the check box checked value (true, false) as the value.
The next step is to put some code into the page that will retrieve this key/value pair and set the checked value when the page is posted back. The most important thing here to remember is that you should be calling this AFTER the init. Yep, after. The reason? Well, if the init is before the view state load, then it makes sense that if you’re attempting to use something that should be in the view state to wait until after it’s loaded right? 🙂
I personally put my custom state handling in the override of the ViewStateLoad method in the page. It’s important to make sure you’ve made the call to the base method before you do your loading though – otherwise you’re still before the view state load…. 🙂
So that’s a quick bit of info on view state. If you’re unsure at all of what view state is, and when it’s loaded, what it’s intended for and what you should and shouldn’t use it for make sure you check out that first article. It really is a highly valuable read!