Limiting view state information on AJAX calls

Question

I have an Entry Form and a GridView on the same page. Selecting a row from the GridView populates the TextBoxes in the Entry Form above it with all the entries of the GridView row.

When this page opens and any row is selected from the GridView, I could see a lot of View State data being sent to the server with each AJAX request. I selected View Source option of the browser to check this. I tried disabling the View State on top of the page by using: EnableViewState = "false", but my application stopped performing correctly.

On selecting any row from the GridView, error is generated and so I re-enabled the View State.

Is there any optimized way to use View State and keep AJAX requests small? Anything related to View State compression as well?

I am using ASP.NET 2.0.

Answer 1

From the moment that you use UpdatePanel, out of the box ajax call you are stick to send all form post data, including the big view state.

You have two ways, one is to make custom made, ajax call that are focused only to the change that you control, and not the full post back that UpdatePanel do.

The other way is to minimize what page send back with each post back, and compress the viewstate.

To compress the viewstate I suggest some pages here that have ready to use source code.

http://www.codeproject.com/Articles/14733/ViewState-Compression

http://www.hanselman.com/blog/ZippingCompressingViewStateInASPNET.aspx

http://www.bloggingdeveloper.com/post/How-To-Compress-ViewState-in-ASPNET-20-ViewState-Compression-with-SystemIOCompression.aspx

and a similar question that I did: How to limit the number of post values on UpdatePanel?

Answer 2

First thing, if you're using an UpdatePanel don't. It's not very efficient. In effect it does as full post back, which you're obviously trying to avoid.

Why not use a GET AJAX request? This will not post anything to the server, other than the URL your passing which could include the Id of the row you need?

Basically:

Create a WebService that will return the data you need.

Bind an onclick event to the Select button on every row on the grid. (Probably easiest done on the bind event server side, use the binding object to get the Id of the row)

In the event call the webservice created above (http://api.jquery.com/jQuery.get/)

In the onSuccess method of the javascript event build the entry as required.

Answer 3

I agree with Kevin M and Aristos. Additionaly there is another way how to minimize transfered ViewState size: store it on server side using custom viewstate provider. This article describes how to create such provider: http://www.codeproject.com/Articles/8001/ViewState-Provider-an-implementation-using-Provide.

What pitfalls arise by using a custom view-state provider?

Answer 4

Short answer is NO.

Here is a way to free page from clutches of viewstate on ajax calls

• Do not depend on the row click event of the grid view.
• Add a link column to the grid view. Do not use server click event.
• link When user clicks the link make an ajax call by sending the id of the row. You will be using a jQuery to make an ajax get call.
• Once the ajax call returns, take the data of the record and find the form elements, again using jQuery and populate them

Answer 5

As stated in all posts, you can do some form of compression in multiple ways, you can implement it yourself or buy a viewstate compressor, but that won't help you too much. What might be interesting is the amount of compression you should expect. Take a look at: RadCompression to gets some info on compression rates, and performance improvements that are generally the same for all choices (free/paid).

My opinion that rates are not satisfactory, and you should look for design alternatives for your problem.

Now, if I understand correctly you want to edit a grid row in a form on the same page. From the comments, you are using an update panel, and by the behavior described you have both your grid and edit form in an update panel. If your page has only the grid and edit form, having them in an update panel won't help at all.

I've made a small example for test purpose and I had a 10 rows grid with 5 columns and an edit form for the 5 fields on the same page. My observations are:

1. Having a grid with no style got me a 1500 char viewstate that amounts to 2KB. Adding styling would get you to a lot more data in viewstate, you can check any paid grid control examples and see that the amount of uncompressed viewstate goes on and on for hundreds of rows.
2. Postbacking the hole page (no update panel) on grid selected item made a request of 3KB and got a response of 6KB
3. Postbacking using an update panel that surrounds the grid and edit form made a request of 3KB and got a response of aprox 6KB. Almost no change in content size.

That's because using an update panel basically means that you are not refreshing the entire page, but only the area inside your updatepanel + viewstate. So, if all your page is surrounded by the update panel, that won't help you at all, and it's not fair to call it AJAX :).

Now, asp.net web forms has it's strengths but my opinion is that nobody likes asp.net web forms anymore, especially when having asp.net mvc / wcf / jquery at hand. Your question proves one of the limitations of asp.net web forms when used as originally intended.

My general solution for your problem would be:

1. Use html only controls for data display (your grid should be a jquery/extjs plugin that displays json data that you get from an WCF ajax enabled web service). Getting rid of the asp grid will help you lower viewstate to almost nothing and make your page source readable.
2. Make a WCF Ajax Web Service and exchange json in the client <-> wcf relation (examples of methods to use are: getgriddata, addnewrow, deleterow, editrow). Having these methods in place means that you won't have to fully postback at all, and that will make your page even nicer and more responsive. Also I would try not to use any code in page events.
3. Call your web service using jquery or other javascript framework that you prefer; making sure you do not use the dreadful asp:ScriptManager will help you get rid of multiple calls to /ScriptResource.axd? and some odd looking in source javascript that does some wiring.