Please see this:
VIEWSTATE" id="_VIEWSTATE" value="/wEPDwUKMTMzMTM1NTAzNA9kFgJmD2QWAgIDD2QWJgIDDw8WBB4LTmF2aWdhdGVVcmwFKGh0dHA6Ly93d3cubGVhcm5kZXZub3cuY29tL1Byb2R1Y3RzLmFzcHgeBFRleHQFCVN1YnNjcmliZWRkAgUPDxYCHwAFHWh0dHA6Ly9vbmxpbmUubGVhcm5kZXZub3cuY29tZGQCBw8PFgIfAAUnaHR0cDovL3d3dy5sZWFybmRldm5vdy5jb20vRGVmYXVsdC5hc3B4ZGQCCQ8PFgIfAAUoaHR0cDovL3d3dy5sZWFybmRldm5vdy5jb20vUHJvZHVjdHMuYXNweGRkAgsPDxYCHwAFJ2h0dHA6Ly93d3cubGVhcm5kZXZub3cuY29tL1NhbXBsZXMuYXNweGRkAg0PDxYCHwAFKWh0dHA6Ly93d3cubGVhcm5kZXZub3cuY29tL3N1YnNjcmliZS5hc3B4ZGQCDw8PFgIfAAUjaHR0cDovL3d3dy5sZWFybmRldm5vdy5jb20vRkFRLmFzcHhkZAIRDw8WAh8ABSxodHRwOi8v........ (it's 10 times bigger but I've removed it)
Is this HTML that ASP.NET produce? And does ASP.NET MVC do the same as well?
That is called ViewState.
ASP.NET MVC does not produce ViewState.
ASP.Net MVC does not produce viewstate, but that doesn't necessarily mean it's faster.
First of all, if you have that much viewstate in an ASP.Net webforms page you're probably doing something wrong. It's not that hard to avoid large viewstates in webforms.
Secondly, the things webforms puts into viewstate mostly substitutes for things mvc pages need to rebuild on each request. This tends to work in mvc's favor on public internet sites, where the bandwidth is both more expensive and slower than using additional server resources. For the private intranet on your company's LAN, it tends to favor webforms where upstream bandwidth from browser to web server is free, plentiful, and fast.
Web forms uses viewstate to maintain control state when you post back to the server. For instance, say you have a text box and a button on a web form. You type something in the text box and click the button. The button performs a post back to the server. When the page reloads, unless you cleared the text box yourself in server-side code, the text box would still contain whatever typed before you clicked the button.
What actually happened was that the data in the text box was stored in the hidden viewstate field and loaded into the text box again upon the page refreshing. The viewstate looks like a jumbled mess because it is base64 encoded. You can store things in the viewstate yourself manually also. In the page_load event of your page just do this:
this.ViewState["someVariable"] = "some value";
Now, if you did this on a blank web form, when you load the page you will see a viewstate field in the html like the one you pasted (except a lot smaller). If you copied the value from that hidden field and pasted it into a viewstate decoder (like this one) you would see someVariable with a value of "some value".
Now put a button on the form and in the button's click even do this:
Response.Write(this.ViewState["someVariable"].ToString());
You will see "some value" written out on the page. What you did was manually store something in the viewstate, it got rendered to the page in that hidden field, then that hidden field got posted back to the server and you read from it to display the data.
This is the primary functionality of web forms. MVC does not use viewstate. MVC relies on another technique known as model binding which would be out of the scope of your question. Google "asp.net mvc model binding" for more information on the way mvc maintains information across posts.
Slightly off-topic example of a viewstate joke:
I have a rather large community site called U413. I recently redesigned it to use ASP.net MVC 2.0. It's a community for programmers and they razz me all the time for using webforms. Well now that it doesn't use webforms I decided to play a little joke on them. MVC does not use viewstate but I went into a webform and generated a viewstate that contained some data and manually pasted the hidden field into my view in my MVC app.
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTE2MTY2ODcyMjkPFgIeE1U0MTNTZWNyZXRBY2Nlc3NLZXkFM2h0dHA6Ly93d3cudTQxMy5jb20vQ29udGVudC9VNDEzU2VjcmV0QWNjZXNzS2V5LmpwZ2RkpshYUvbSiUuE0YaYNBH0rvTGj4qEcquSqQeUs9ZpuIQ=" />
Already several people have gone snooping through the html source hoping to find little secrets or exploits and encountered this. They immediately decoded it and got a good laugh. Copy the value and paste it into the decoder I linked to earlier if you want to see.
Related
I just got started with ASP.NET MVC, and I suddenly asked myself: why does ASP.NET need ViewState in the first place? FormData is actually holding the state across postbacks. ViewState is only needed if the state of the control is changed, and that change is NOT included in FormData. For example, what if the event handler changed the control's font color?
Two questions:
For WebForms, is that the reason for the need of ViewState?
If yes, how can MVC "maintain a control's property which is NOT in FormData"?
MVC and WebForms are very different in this regard. The point of WebForms was to help ease WinFroms developers in to web development. For that reason the infrastructure of WebForms simulates statefullness whenever it can. ViewState is one of the ways this is implemented. Since the browser only posts back form fields, in WebForms the entire page is one big form and the entire page is posted to the server. The ViewState is a hidden field, which holds everything BUT the data in the inputs, selects, etc. which the browser posts by default.
On the other hand MVC does not try to simulate statefullness. It works more directly with HTTP and the basic rules of a stateless system. So when you post a form ONLY the data in the inputs, selects, etc. gets posted. Nothing else makes it back to the server.
This is why, if you want to return the same view after a post with the updated data, you have to refill the ViewModel with data like you did in the original get method. MVC does not take care of this for you like WebForms.
Regarding why View State in first place, your explanation is related. View State is used to persist state across Post Backs and mainly to handle properties updated programmatic for example page with label and button and you have event handler for the button that change the label front color to red , in the page load the controls initiate the label with default color however when the button click it change the label color to red and keep that change in the view state so if anything triggered post back then after loading the controls in the page load it sets the front color to the value already saved inside the viewstate
For more details please check the following link http://msdn.microsoft.com/en-us/library/ms972976.aspx#viewstate_topic3
MVC doesn't have viewstate, MVC is based on model binding so when a form is posted MVC framework read the httprequest parameters and try to create strongly typed object from that request and you can create your own model binder that tell the MVC how to read the http request
This is 10KB in my HTML source:
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKLTEyOTAwODE4Nw9kFgJmD2QWAgIDD2QWBGYPZBYEAgEPDxYCHgdWaXNpYmxlaGRkAgIPZBYIAgEPFgIfAGdkAgMPDxYEHgRUZXh0BQNUb20eC05hdmlnYXRlVXJsBQt+L3VzZXJzL1RvbWRkAgUPFgIfAQUFMSwzMjZkAgcPDxYCHwIFCH4vTG9nb3V0ZGQCAg9kFgQCEA9kFgICAQ8WAh8BBXk8YSBhZGR0aGlzOmRlc2NyaXB0aW9uPSJTaGFyZSBTY2lycmEiIGFkZHRoaXM6dXJsPSJodHRwOi8vMTI3LjAuMC4xL3NjaXJyYW5ldy9ibG9nLzM5L3dlZWVlIiBjbGFzcz0iYWRkdGhpc19jb3VudGVyIj48L2E+ZAIUD2QWEAIBDxYCHwBnFgICAQ8WAh4EaHJlZgUifi9BZG1pbmJsb2cuYXNweD9hY3Rpb249ZWRpdCZJRD0zOWQCAw8WAh8BBQ0xNyBBcHJpbCAyMDExZAIFDxYCHwEFBVdlZWVlZAIHDxYCHwEFDjxwPm9ya2dyZ3I8L3A+ZAIJD2QWAmYPZBYCAgMPFgIeC18hSXRlbUNvdW50AgMWBmYPZBYCAgEPDxYGHwEFBEJsb2ceB1Rvb2xUaXAFH090aGVyIHJlc291cmNlcyByZWxhdGVkIHRvIEJsb2cfAgULfi90YWdzL2Jsb2dkZAIBD2QWAgIBDw8WBh8BBQtDb25zdHJ1Y3QtMR8FBSZPdGhlciByZXNvdXJjZXMgcmVsYXRlZCB0byBDb25zdHJ1Y3QtMR8CBRJ+L3RhZ3MvY29uc3RydWN0LTFkZAICD2QWAgIBDw8WBh8BBQtDb25zdHJ1Y3QtMh8FBSZPdGhlciByZXNvdXJjZXMgcmVsYXRlZCB0byBDb25zdHJ1Y3QtMh8CBRJ+L3RhZ3MvY29uc3RydWN0LTJkZAILDw8WBB8CBQt+L3VzZXJzL1RvbR8BBQNUb21kZAINDw8WBB8CBRh+L2Jsb2cvMzkvd2VlZWUvY29tbWVudHMfAQULMTAgY29tbWVudHNkZAIPD2QWAmYPZBYGAgIPFgIfBAIKFhRmD2QWDgIDDw8WBB4IQ3NzQ2xhc3MFGWNvbW1lbnQtaGVhZCBjaC1oaWdobGlnaHQeBF8hU0ICAmQWBAIBDxYCHwEFWjxhYmJyIGNsYXNzPSJ0aW1lYWdvIiB0aXRsZT0iMjAxMS0wNC0yM1QxNzozNToyNC45MjAwMDAwIj4yMyBBcHJpbCAyMDExIGF0IDE3OjM1OjI0PC9hYmJyPmQCAw8PFgYfAgULfi91c2Vycy9Ub20fBQUeVmlzaXQgdGhpcyBnYW1lIG1ha2VycyBwcm9maWxlHwEFA1RvbWRkAgUPDxYEHwIFC34vdXNlcnMvVG9tHwUFIFRvbSBtYWtlcyBnYW1lcyB3aXRoIENvbnN0cnVjdCAyZBYCZg8PFgQeCEltYWdlVXJsBUlodHRwOi8vd3d3LmdyYXZhdGFyLmNvbS9hdmF0YXIvNTI3MWQzMjgzZGI5NTdlZjNhODY3NjFlZDE1YzE2OTY/cj1wZyZzPTgwHwUFDlRvbSdzIEdyYXZhdGFyZGQCBw8PFgYfBgUQcyBjb21tZW50LXJlcG9ydB8FBRBSZXBvcnQgdGhpcyBwb3N0HwcCAmRkAgkPDxYGHwYFEHMgY29tbWVudC1kZWxldGUfBQUQRGVsZXRlIHRoaXMgcG9zdB8HAgJkZAILDw8WBh8GBQ5zIGNvbW1lbnQtZWRpdB8FBQ5FZGl0IHRoaXMgcG9zdB8HAgJkZAINDw8WBh8GBQ9zIGNvbW1lbnQtcXVvdGUfBQUPUXVvdGUgdGhpcyBwb3N0HwcCAhYCHwMFBSNQb3N0ZAIPDxYCHwEFoAM8ZGl2IGNsYXNzPSJjb21tZW50LXF1b3RlciI+Q29tbWVudCBieSA8c3Ryb25nPlRvbTwvc3Ryb25nPjxiciAvPjxiciAvPndlZiB3ZSBmIHdmZTwvZGl2PjxkaXYgY2xhc3M9ImNvbW1lbnQtcXVvdGVyIj5Db21tZW50IGJ5IDxzdHJvbmc+VG9tPC9zdHJvbmc+PGJyIC8+PGJyIC8+cGlsbHV1w7rDuiB0dCB0IGggdGggdGggdGggdGggdGg8L2Rpdj48ZGl2IGNsYXNzPSJjb21tZW50LXF1b3RlciI+Q29tbWVudCBieSA8c3Ryb25nPlRvbTwvc3Ryb25nPjxiciAvPjxiciAvPnBpbGx1dcO6w7ogdHQgdCBoIHRoIHRoIHRoIHRoIHRoPC9kaXY+PGRpdiBjbGFzcz0iY29tbWVudC1xdW90ZXIiPkNvbW1lbnQgYnkgPHN0cm9uZz5Ub208L3N0cm9uZz48YnIgLz48YnIgLz5waWxsdXXDusO6IHR0IHQgaCB0aCB0aCB0aCB0aCB0aDwvZGl2PmQCAQ9kFg4CAw8PFgQfBgUZY29tbWVudC1oZWFkIGNoLWhpZ2hsaWdodB8HAgJkFgQCAQ8WAh8BBVo8YWJiciBjbGFzcz0idGltZWFnbyIgdGl0bGU9IjIwMTEtMDQtMjNUMTc6Mjk6MjkuMjQ3MDAwMCI+MjMgQXByaWwgMjAxMSBhdCAxNzoyOToyOTwvYWJicj5kAgMPDxYGHwIFC34vdXNlcnMvVG9tHwUFHlZpc2l0IHRoaXMgZ2FtZSBtYWtlcnMgcHJvZmlsZR8BBQNUb21kZAIFDw8WBB8CBQt+L3VzZXJzL1RvbR8FBSBUb20gbWFrZXMgZ2FtZXMgd2l0aCBDb25zdHJ1Y3QgMmQWAmYPDxYEHwgFSWh0dHA6Ly93d3cuZ3JhdmF0YXIuY29tL2F2YXRhci81MjcxZDMyODNkYjk1N2VmM2E4Njc2MWVkMTVjMTY5Nj9yPXBnJnM9ODAfBQUOVG9tJ3MgR3JhdmF0YXJkZAIHDw8WBh8GBRBzIGNvbW1lbnQtcmVwb3J0HwUFEFJlcG9ydCB0aGlzIHBvc3QfBwICZGQCCQ8PFgYfBgUQcyBjb21tZW50LWRlbGV0ZR8FBRBEZWxldGUgdGhpcyBwb3N0HwcCAmRkAgsPDxYGHwYFDnMgY29tbWVudC1lZGl0HwUFDkVkaXQgdGhpcyBwb3N0HwcCAmRkAg0PDxYGHwYFD3MgY29tbWVudC1xdW90ZR8FBQ9RdW90ZSB0aGlzIHBvc3QfBwICFgIfAwUFI1Bvc3RkAg8PFgIfAQUyPGRpdiBjbGFzcz0iY29tbWVudC1xdW90ZXIiPnJlZ2c8L2Rpdj53ZWYgd2UgZiB3ZmVkAgIPZBYOAgMPDxYEHwYFGWNvbW1lbnQtaGVhZCBjaC1oaWdobGlnaHQfBwICZBYEAgEPFgIfAQVaPGFiYnIgY2xhc3M9InRpbWVhZ28iIHRpdGxlPSIyMDExLTA0LTIzVDE3OjI4OjIzLjM2NzAwMDAiPjIzIEFwcmlsIDIwMTEgYXQgMTc6Mjg6MjM8L2FiYnI+ZAIDDw8WBh8CBQt+L3VzZXJzL1RvbR8FBR5WaXNpdCB0aGlzIGdhbWUgbWFrZXJzIHByb2ZpbGUfAQUDVG9tZGQCBQ8PFgQfAgULfi91c2Vycy9Ub20fBQUgVG9tIG1ha2VzIGdhbWVzIHdpdGggQ29uc3RydWN0IDJkFgJmDw8WBB8IBUlodHRwOi8vd3d3LmdyYXZhdGFyLmNvbS9hdmF0YXIvNTI3MWQzMjgzZGI5NTdlZjNhODY3NjFlZDE1YzE2OTY/cj1wZyZzPTgwHwUFDlRvbSdzIEdyYXZhdGFyZGQCBw8PFgYfBgUQcyBjb21tZW50LXJlcG9ydB8FBRBSZXBvcnQgdGhpcyBwb3N0HwcCAmRkAgkPDxYGHwYFEHMgY29tbWVudC1kZWxldGUfBQUQRGVsZXRlIHRoaXMgcG9zdB8HAgJkZAILDw8WBh8GBQ5zIGNvbW1lbnQtZWRpdB8FBQ5FZGl0IHRoaXMgcG9zdB8HAgJkZAINDw8WBh8GBQ9zIGNvbW1lbnQtcXVvdGUfBQUPUXVvdGUgdGhpcyBwb3N0HwcCAhYCHwMFBSNQb3N0ZAIPDxYCHwEFH1tRVU9URV1yZWdnWy9RVU9URV13ZWYgd2UgZiB3ZmVkAgMPZBYOAgMPDxYEHwYFGWNvbW1lbnQtaGVhZCBjaC1oaWdobGlnaHQfBwICZBYEAgEPFgIfAQVaPGFiYnIgY2xhc3M9InRpbWVhZ28iIHRpdGxlPSIyMDExLTA0LTIzVDE3OjI3OjU1Ljk1NzAwMDAiPjIzIEFwcmlsIDIwMTEgYXQgMTc6Mjc6NTU8L2FiYnI+ZAIDDw8WBh8CBQt+L3VzZXJzL1RvbR8FBR5WaXNpdCB0aGlzIGdhbWUgbWFrZXJzIHByb2ZpbGUfAQUDVG9tZGQCBQ8PFgQfAgULfi91c2Vycy9Ub20fBQUgVG9tIG1ha2VzIGdhbWVzIHdpdGggQ29uc3RydWN0IDJkFgJmDw8WBB8IBUlodHRwOi8vd3d3LmdyYXZhdGFyLmNvbS9hdmF0YXIvNTI3MWQzMjgzZGI5NTdlZjNhODY3NjFlZDE1YzE2OTY/cj1wZyZzPTgwHwUFDlRvbSdzIEdyYXZhdGFyZGQCBw8PFgYfBgUQcyBjb21tZW50LXJlcG9ydB8FBRBSZXBvcnQgdGhpcyBwb3N0HwcCAmRkAgkPDxYGHwYFEHMgY29tbWVudC1kZWxldGUfBQUQRGVsZXRlIHRoaXMgcG9zdB8HAgJkZAILDw8WBh8GBQ5zIGNvbW1lbnQtZWRpdB8FBQ5FZGl0IHRoaXMgcG9zdB8HAgJkZAINDw8WBh8GBQ9zIGNvbW1lbnQtcXVvdGUfBQUPUXVvdGUgdGhpcyBwb3N0HwcCAhYCHwMFBSNQb3N0ZAIPDxYCHwEFdDxkaXYgY2xhc3M9ImNvbW1lbnQtcXVvdGVyIj5Db21tZW50IGJ5IDxzdHJvbmc+VG9tPC9zdHJvbmc+PGJyIC8+PGJyIC8+T2sgbmljZSBvbmUgOi0pIExvdmluZyB0aGlzITwvZGl2Pk5vIHByb2JsZW1vZAIED2QWDgIDDw8WBB8GBRljb21tZW50LWhlYWQgY2gtaGlnaGxpZ2h0HwcCAmQWBAIBDxYCHwEFWjxhYmJyIGNsYXNzPSJ0aW1lYWdvIiB0aXRsZT0iMjAxMS0wNC0yM1QxNzoyNzoyNy45ODcwMDAwIj4yMyBBcHJpbCAyMDExIGF0IDE3OjI3OjI3PC9hYmJyPmQCAw8PFgYfAgULfi91c2Vycy9Ub20fBQUeVmlzaXQgdGhpcyBnYW1lIG1ha2VycyBwcm9maWxlHwEFA1RvbWRkAgUPDxYEHwIFC34vdXNlcnMvVG9tHwUFIFRvbSBtYWtlcyBnYW1lcyB3aXRoIENvbnN0cnVjdCAyZBYCZg8PFgQfCAVJaHR0cDovL3d3dy5ncmF2YXRhci5jb20vYXZhdGFyLzUyNzFkMzI4M2RiOTU3ZWYzYTg2NzYxZWQxNWMxNjk2P3I9cGcmcz04MB8FBQ5Ub20ncyBHcmF2YXRhcmRkAgcPDxYGHwYFEHMgY29tbWVudC1yZXBvcnQfBQUQUmVwb3J0IHRoaXMgcG9zdB8HAgJkZAIJDw8WBh8GBRBzIGNvbW1lbnQtZGVsZXRlHwUFEERlbGV0ZSB0aGlzIHBvc3QfBwICZGQCCw8PFgYfBgUOcyBjb21tZW50LWVkaXQfBQUORWRpdCB0aGlzIHBvc3QfBwICZGQCDQ8PFgYfBgUPcyBjb21tZW50LXF1b3RlHwUFD1F1b3RlIHRoaXMgcG9zdB8HAgIWAh8DBQUjUG9zdGQCDw8WAh8BBXA8ZGl2IGNsYXNzPSJjb21tZW50LXF1b3RlciI+Q29tbWVudCBieSA8c3Ryb25nPlRvbTwvc3Ryb25nPjxiciAvPjxiciAvPk9rIG5pY2Ugb25lIDotKSBMb3ZpbmcgdGhpcyE8L2Rpdj5UaGFua3MhZAIFD2QWDgIDDw8WBB8GBRljb21tZW50LWhlYWQgY2gtaGlnaGxpZ2h0HwcCAmQWBAIBDxYCHwEFWjxhYmJyIGNsYXNzPSJ0aW1lYWdvIiB0aXRsZT0iMjAxMS0wNC0yMlQxNDozOToyMy4xMjAwMDAwIj4yMiBBcHJpbCAyMDExIGF0IDE0OjM5OjIzPC9hYmJyPmQCAw8PFgYfAgULfi91c2Vycy9Ub20fBQUeVmlzaXQgdGhpcyBnYW1lIG1ha2VycyBwcm9maWxlHwEFA1RvbWRkAgUPDxYEHwIFC34vdXNlcnMvVG9tHwUFIFRvbSBtYWtlcyBnYW1lcyB3aXRoIENvbnN0cnVjdCAyZBYCZg8PFgQfCAVJaHR0cDovL3d3dy5ncmF2YXRhci5jb20vYXZhdGFyLzUyNzFkMzI4M2RiOTU3ZWYzYTg2NzYxZWQxNWMxNjk2P3I9cGcmcz04MB8FBQ5Ub20ncyBHcmF2YXRhcmRkAgcPDxYGHwYFEHMgY29tbWVudC1yZXBvcnQfBQUQUmVwb3J0IHRoaXMgcG9zdB8HAgJkZAIJDw8WBh8GBRBzIGNvbW1lbnQtZGVsZXRlHwUFEERlbGV0ZSB0aGlzIHBvc3QfBwICZGQCCw8PFgYfBgUOcyBjb21tZW50LWVkaXQfBQUORWRpdCB0aGlzIHBvc3QfBwICZGQCDQ8PFgYfBgUPcyBjb21tZW50LXF1b3RlHwUFD1F1b3RlIHRoaXMgcG9zdB8HAgIWAh8DBQUjUG9zdGQCDw8WAh8BBR90cmhoIHJ0aCAgcnRocmhoIHRyIGhydCBocnQgcmh0ZAIGD2QWDgIDD2QWBAIBDxYCHwEFWjxhYmJyIGNsYXNzPSJ0aW1lYWdvIiB0aXRsZT0iMjAxMS0wNC0yMlQwMDozOTozNC45NDAwMDAwIj4yMiBBcHJpbCAyMDExIGF0IDAwOjM5OjM0PC9hYmJyPmQCAw8PFgYfAgURfi91c2Vycy9DaGVlc2VCb3kfBQUeVmlzaXQgdGhpcyBnYW1lIG1ha2VycyBwcm9maWxlHwEFCUNoZWVzZUJveWRkAgUPDxYEHwIFEX4vdXNlcnMvQ2hlZXNlQm95HwUFJkNoZWVzZUJveSBtYWtlcyBnYW1lcyB3aXRoIENvbnN0cnVjdCAyZBYCZg8PFgQfCAVJaHR0cDovL3d3dy5ncmF2YXRhci5jb20vYXZhdGFyL2ZjMjE2Nzc4ZjYzOGM4N2FmODZhNjI0MWNhMzZiM2EyP3I9cGcmcz04MB8FBRRDaGVlc2VCb3kncyBHcmF2YXRhcmRkAgcPDxYGHwYFEHMgY29tbWVudC1yZXBvcnQfBQUQUmVwb3J0IHRoaXMgcG9zdB8HAgJkZAIJDw8WBh8GBRBzIGNvbW1lbnQtZGVsZXRlHwUFEERlbGV0ZSB0aGlzIHBvc3QfBwICZGQCCw8PFgYfBgUOcyBjb21tZW50LWVkaXQfBQUORWRpdCB0aGlzIHBvc3QfBwICZGQCDQ8PFgYfBgUPcyBjb21tZW50LXF1b3RlHwUFD1F1b3RlIHRoaXMgcG9zdB8HAgIWAh8DBQUjUG9zdGQCDw8WAh8BBTFMb3ZpbmcgdGhpcyBibG9nIHBvc3QgdGhhbmtzIGZvciBpdCwgKzEhICBHbCBsb2whZAIHD2QWDgIDDw8WBB8GBRljb21tZW50LWhlYWQgY2gtaGlnaGxpZ2h0HwcCAmQWBAIBDxYCHwEFWjxhYmJyIGNsYXNzPSJ0aW1lYWdvIiB0aXRsZT0iMjAxMS0wNC0yMlQwMDoxMzowNC44NTMwMDAwIj4yMiBBcHJpbCAyMDExIGF0IDAwOjEzOjA0PC9hYmJyPmQCAw8PFgYfAgULfi91c2Vycy9Ub20fBQUeVmlzaXQgdGhpcyBnYW1lIG1ha2VycyBwcm9maWxlHwEFA1RvbWRkAgUPDxYEHwIFC34vdXNlcnMvVG9tHwUFIFRvbSBtYWtlcyBnYW1lcyB3aXRoIENvbnN0cnVjdCAyZBYCZg8PFgQfCAVJaHR0cDovL3d3dy5ncmF2YXRhci5jb20vYXZhdGFyLzUyNzFkMzI4M2RiOTU3ZWYzYTg2NzYxZWQxNWMxNjk2P3I9cGcmcz04MB8FBQ5Ub20ncyBHcmF2YXRhcmRkAgcPDxYGHwYFEHMgY29tbWVudC1yZXBvcnQfBQUQUmVwb3J0IHRoaXMgcG9zdB8HAgJkZAIJDw8WBh8GBRBzIGNvbW1lbnQtZGVsZXRlHwUFEERlbGV0ZSB0aGlzIHBvc3QfBwICZGQCCw8PFgYfBgUOcyBjb21tZW50LWVkaXQfBQUORWRpdCB0aGlzIHBvc3QfBwICZGQCDQ8PFgYfBgUPcyBjb21tZW50LXF1b3RlHwUFD1F1b3RlIHRoaXMgcG9zdB8HAgIWAh8DBQUjUG9zdGQCDw8WAh8BBRdlZyBlICBnIGdlIGcgZyBnIGcgZyBlZ2QCCA9kFg4CAw8PFgQfBgUZY29tbWVudC1oZWFkIGNoLWhpZ2hsaWdodB8HAgJkFgQCAQ8WAh8BBVo8YWJiciBjbGFzcz0idGltZWFnbyIgdGl0bGU9IjIwMTEtMDQtMjFUMjM6MzA6NTAuNjMzMDAwMCI+MjEgQXByaWwgMjAxMSBhdCAyMzozMDo1MDwvYWJicj5kAgMPDxYGHwIFC34vdXNlcnMvVG9tHwUFHlZpc2l0IHRoaXMgZ2FtZSBtYWtlcnMgcHJvZmlsZR8BBQNUb21kZAIFDw8WBB8CBQt+L3VzZXJzL1RvbR8FBSBUb20gbWFrZXMgZ2FtZXMgd2l0aCBDb25zdHJ1Y3QgMmQWAmYPDxYEHwgFSWh0dHA6Ly93d3cuZ3JhdmF0YXIuY29tL2F2YXRhci81MjcxZDMyODNkYjk1N2VmM2E4Njc2MWVkMTVjMTY5Nj9yPXBnJnM9ODAfBQUOVG9tJ3MgR3JhdmF0YXJkZAIHDw8WBh8GBRBzIGNvbW1lbnQtcmVwb3J0HwUFEFJlcG9ydCB0aGlzIHBvc3QfBwICZGQCCQ8PFgYfBgUQcyBjb21tZW50LWRlbGV0ZR8FBRBEZWxldGUgdGhpcyBwb3N0HwcCAmRkAgsPDxYGHwYFDnMgY29tbWVudC1lZGl0HwUFDkVkaXQgdGhpcyBwb3N0HwcCAmRkAg0PDxYGHwYFD3MgY29tbWVudC1xdW90ZR8FBQ9RdW90ZSB0aGlzIHBvc3QfBwICFgIfAwUFI1Bvc3RkAg8PFgIfAQUcT2sgbmljZSBvbmUgOi0pIExvdmluZyB0aGlzIWQCCQ9kFg4CAw8PFgQfBgUZY29tbWVudC1oZWFkIGNoLWhpZ2hsaWdodB8HAgJkFgQCAQ8WAh8BBVo8YWJiciBjbGFzcz0idGltZWFnbyIgdGl0bGU9IjIwMTEtMDQtMjBUMDA6MDE6NDcuNjY3MDAwMCI+MjAgQXByaWwgMjAxMSBhdCAwMDowMTo0NzwvYWJicj5kAgMPDxYGHwIFC34vdXNlcnMvVG9tHwUFHlZpc2l0IHRoaXMgZ2FtZSBtYWtlcnMgcHJvZmlsZR8BBQNUb21kZAIFDw8WBB8CBQt+L3VzZXJzL1RvbR8FBSBUb20gbWFrZXMgZ2FtZXMgd2l0aCBDb25zdHJ1Y3QgMmQWAmYPDxYEHwgFSWh0dHA6Ly93d3cuZ3JhdmF0YXIuY29tL2F2YXRhci81MjcxZDMyODNkYjk1N2VmM2E4Njc2MWVkMTVjMTY5Nj9yPXBnJnM9ODAfBQUOVG9tJ3MgR3JhdmF0YXJkZAIHDw8WBh8GBRBzIGNvbW1lbnQtcmVwb3J0HwUFEFJlcG9ydCB0aGlzIHBvc3QfBwICZGQCCQ8PFgYfBgUQcyBjb21tZW50LWRlbGV0ZR8FBRBEZWxldGUgdGhpcyBwb3N0HwcCAmRkAgsPDxYGHwYFDnMgY29tbWVudC1lZGl0HwUFDkVkaXQgdGhpcyBwb3N0HwcCAmRkAg0PDxYGHwYFD3MgY29tbWVudC1xdW90ZR8FBQ9RdW90ZSB0aGlzIHBvc3QfBwICFgIfAwUFI1Bvc3RkAg8PFgIfAQUgcGlsbHV1w7rDuiB0dCB0IGggdGggdGggdGggdGggdGhkAgYPZBYCAgEPDxYCHglNYXhMZW5ndGgC9ANkZAIIDw8WAh8AaGRkZAx0/0RvMYX4SKMMjV5pXc+cjNqDEEepI0JWzIxpxOzG" />
This represents ~50% of the entire size of the page.
Why does it do this, why so long? Can I do anything about it? It's bad for mobile users.
What is this view state anyway and how to mitigate its size
In Asp.net WebForms every control saves its state because HTTP protocol is stateless and Asp.net WebForms pages bypass that by saving every control's state in this Base 64 encoded string. This is the only way for Asp.net framework to know whether some control's value has changed or not. But... This automatically means that static controls that don't get POSTed back to server (like label for instance) don't need to save their state. You can always set their EnableViewState="false".
Unfortunately this can't be set without any other code changes on other controls, that do get POSTed back (every server-side control that renders some sort of an input in HTML). This basically means that setting EnableViewState="false" on page level (within #Page directive) will have consequences that are seen as controls loosing their values, controls not firing certain events etc.
So, the more server-side controls you have the larger it will get (without turning it off on certain controls).
But I wouldn't worry if its size is 10k. That will go back and forth rather fast and painless. You will have problems when it gets much larger. I once worked on a project and we had an issue with a certain page (done by less experienced developer) where view state grew over 1MB. Imagine that. What a slowdown!
How to turn it off completely on page level
When you turn view state off on page level you have to be aware that certain controls that were loaded (or better said data bound) in on of your page's events, will have to be reloaded each time your page gets POSTed back at server. Otherwise they will show up as empty when your page gets back to the client.
Your server controls are filling the ViewState with data they will need on postback. If your page does not postback you can just disable the ViewState for the page.
To disable ViewState for the page you can just add EnableViewState="false" to the #Page directive. Please be aware you should only use this as a solution if you are 100% sure the page does not postback.
You also might want to check this MSDN article to get a better idea of what the ViewState does.
Disable viewstate for static controls, like a gridview.
Check out this question for more info:
If you are concerned about the viewstate on the client side, then think about storing it on the server side. Perhaps in a session variable. Take a look at this article as there is statistical comparison given. Download the solution and check out how to store it on the server side.
An Analysis of Keeping ViewState out of the Page
This article explained it neatly to me in the past: Taking a Bite Out of ASP.NET ViewState.
Basically viewstate's on by default and, depending on which controls you use, it can get out of hand pretty fast. Especially data controls like the gridview are responsible for massive injection of viewstate. You can disable that on a per control basis by setting the EnableViewState property to false. Be careful however as taking out viewstate might also take out functionality of the controls. So do it one by one and test test test.
Another way, and likely better for mobile, is to make use of ASP.NET MVC instead which doesn't have to deal with automatic viewstate injection.
I am working in a CMS where we use tokens ( which is turned into a user control. Is there a way to add the user control into an attribute value for our template style?
example :
<div class="<$tokenName/$>" />
this currently outputs an encoded user control, which is then not parsed by IIS.
Short answer: this is not possible.
Longer answer...
It's not IIS's job to parse the control... that happens when IIS hands off the request to the ASP.NET engine. ASP.NET does a single-pass parse through your ASPX before the Page lifecycle even starts... this is why controls you delcare in the ASPX are available during the Init event. Whenever your CMS expands "$tokenName", you are far past the point at which ASP.NET is interpreting your markup.
If you're having trouble with that, here's a thought experiment for you: What happens when $token expands into a user control that has some other $token2 control embedded in it? And that control contains some other $token3? How many times are you going to try and parse/expand/interpret your markup?
For example,
If I have a textbox with runat=server on a page, The value will be posted back to the server so I can access the properties in the code-behind.
However, under the following situations, does it still hold true?
A textbox with runat=server but does not appear in the function that is post back to. For example, a button is also on the page, when clicked a post back occurs and within the method that is raised, this textbox was not used.
Within a MasterPage, will a textbox residing on the Masterpage itself be posted back?
Because just thinking, isn't this mechanism bloated in nature?
If all input controls and its value are posted back on every single button click (even when the input control is not needed), doesn't this deteriorate performance?
Having just one Form Tag on the page really restricts us to using this mechanism?
Truly Understanding ViewState is a must read article on the subject of ASP.NET ViewState
There are several options to cut down on the bloat (and yes, there's a lot of it when dealing with lots of controls):
Use AJAX to post only the items required - although be careful to allow clients that don't have JavaScript enabled to still use the page/ site.
The MVC framework allows multiple form tags to be used so you can group sections if needs be.
Set the EnableViewState to false on pages/ controls.
Break up your pages into smaller ones.
Additionally, check out this brilliant graphical representation of the Page Life Cycle in ASP.NET.
Every input on the page is posted back fully unless you use ajax, because of the single form tag. Welcome to asp.net...
As long as the method that you're hitting on the server-side is a non-static member of the page's class, it'll have access to the textbox and all other controls on the page.
And yes, all controls rendered to the browser (whether in the MasterPage, user control, etc.) will be available on post-back.
You may want to look into Understanding ASP.NET View State.
There surely are performance hits with this architecture, but (depending on complexity of the page) it's usually not an issue from the server load perspective, because hardware upgrades are typically cheaper than additional programming hours spend on optimizing application performance.
With that said, (and as others have pointed out) look into using AJAX if you want to avoid whole page-level postbacks to the server.
Yes, it's all posted back, and yes it can cause bloat. I'm sure if you search for ViewState you will find plenty of people ranting about it and how to minimise it :)
Yes your text box will be available in both cases, yes it is bloated. This is where AJAX comes into play. Using AJAX you can send just the data you need.
If you want to send a minimal ammount of data, you could use a Page Method (static method on page decorated so the script manager builds javascript to call it or you could call it using jquery or other methods), or a script enabled web service works nice as well.
You also have viewstate which can get very large. ASP.Net MVC is a new paradigm instead of using WebForms which doesn't have view state, or post backs. It embraces HTTP instead of hidding it giving developers more control.
The textbox data would be posted back as noted. In addition to using Ajax, disabling view state greatly imporoves your page's performance though even then data in properties critical to the functioning of controls (Control state) would still be posted back.
If you didn't have postback for every control on the form, you wouldn't be able to access it in code-behind. I.e. if in your button press you wanted to modify the property of the text control you couldn't do that because ASP.Net would know nothing about the text control.
Since the communication between the server and the client is stateless and every time a page is server the server forgets all about it Postbacks are important if you want to work with the same page again. No matter what programming language you use, this or similar mechanism exists for processing server side code.
If you wish to minimize postback (viewstate size), do this.
Set enableviewstate=false on all controls that you don't want posted back.
Use AJAX and web services wherever possible (and don't use UpdatePanel).
Use HTML control as much as possible instead of ASP.Net controls.
Hmm.. There are some excellent suggestion in other answers and good links too.
You've pretty much hit the nail on the head with vanilla ASP.NET - it's not very good! In both the instances you describe the answer is yes - the textbox will be sent with the form.
The whole postback/ViewState problem is a bit of a pain, one of the first things any competent ASP.NET developer learns to do is avoid them!
I am moving from classic ASP to ASP.NET and have encountered what many of you already know as "viewstate". I might be jumping the gun with my assumption, but it looks highly cumbersome. I have developed many ASP forms in the past and never had issues with keeping state. Is there another way OR am I going to have to learn this Viewstate thing in ASP.NET? I am using Visual Studio 2008, VB.NET as the code behind language and Framework v3.5 with SQL Server 2005.
You don't have to. Check out MVC framework. It eliminates ViewState and works as old ASP (at least from this point of view).
This series of posts is must reading for understanding ViewState
I disable it and do most of my work in Page_Init instead of Load (values are still maintained because of ControlState). This setup has worked out well for me.
ViewState is optional, but helpful. What ViewState is, is all the changes which occur on a control on the SERVER SIDE. So, if you're assigning text to a label, and you want that text to persist without the need to reassign it on every postback, then you'll want to maintain that. Another example where I always leave ViewState on is anything databound.
That said, there are times when it's helpful to turn ViewState off for that same reason. For example, the one place where I always turn ViewState off is a MESSAGE label. That way, when I have to print out a message to the user (one which should only appear once and then go away) I just add the text to the label and then forget about it. During the next PostBack, the label will automatically revert to the text which is found in the ASPX declaration for that control (in this case an empty string).
Now, note that this has nothing to do with the form collection, which are the values posted to IIS during the PostBack. The form collection sends the values that the user enters into form elements (textboxes, checkboxes, droplists,etc). These .NET will populate into the appropriate place--and this occurs AFTER ViewState has been processed.
This way, if you send a textbox with the phrase "hi there" to the client, the user changes it to "See ya" and then submits the form, what the textbox will have by the time the Page_Load event fires is a textbox with "See ya" in the TEXT attribute.
In classic ASP we always just used a HIDDEN field to do the job. Viewstate is just a way of doing that for you automatically. Trust me the learning curve is not as high as you might think.
Some controls are deeply crippled when you turn ViewState off, so be prepared to address these concerns. It's easiest to just be lazy and leave it on, but left unchecked, ViewState can easily account for 30% of the size of your HTML.
For example, say you have a DropDown, and you bind it to a list of Fruits. You bind it in the if(! IsPostBack) { } block in the page load. If you turn off ViewState, you'll lose the items when you click a button. They need to be bound every page load. You'll also lose your selected index, so you'd need to pull that off of the Request.Form[] variables.
Viewstate is part of the package when you are working with ASP.NET. For a basic page/website you shouldn't have to 'know' how to use Viewstate. It just gets used as you put controls on pages.
It's pretty hard to avoid Viewstate with ASP.NET because even if you turn it off at the project level, some individual controls still use Viewstate to persist their information.
If you don't want to deal with Viewstate, consider using the ASP.NET MVC framework. You will likely be more comfortable with the MVC framework coming from Classic ASP.
ViewState is completely optional in almost all if not all cases. ASP.NET re-populates fields automatically even if ViewStateEnabled=false. I've been using ASP.NET for 5 or 6 years and have never had to depend on ViewState. I even disable it when I can.
ViewState works automatically for the most part. It's just how ASP.NET keeps track of the current state of all it's controls.
You can manually use viewstate too, if you want to store some extra data. That is as simple as:
Viewstate["Key"] = value;
The only caveat with that is that any object you store in viewstate must be serializable.
I can definitely recommend avoiding ViewState in DataGrids and DropDownLists because I just recently started doing it myself. I didn't do this for fun, I had to fix a page that had grown so large that it was causing other problems. But this turned out to be easy, and the results were so dramatic that I am very pleased. Of course for a small simple app or for small amounts of data this will not be necessary, but on the other hand it's good to be consistent (always go from known to known so you can continually improve your process...), and why carry around extra baggage, ever?
This will require a little manual intervention on your part. For example, if you turn off viewstate for drop down lists, you'll need to rebind them on each postback, and then restore the SelectedValue from the Request object. You'll need to read up on this, but google has lots of readily available information.
Viewstate is kept automatically for asp.net controls "rooted" to the page. There is little you have to do, the values and some other information is passed in a hidden input B64 encoded. You can look at it if you want, but it doesn't matter, it's all handled automagically for you.
If you're writing code for your own consumption, you can just turn it off and not worry.
Presumably you're going to maintain Web Forms code written by other people, so you should know what the config options and pain points are. Top few I can think of
how to disable it at site, page and control level
why MachineKey is relevant in web farms
why your event log is full of ViewStateAuthentication errors
what ViewStateUserKey is
In terms of actual learning curve this is probably a thorough read of a couple of MSDN articles.
ViewState is a necessary evil inherent to the web forms metaphor. I personally find this methodology obsolete, bloated and generally not web-friendly. Better check out MVC framework as suggested above.
I suggest you avoid the temptation to use ViewState as a "cache" to pass data back and forth (I've seen websites doing this because of clustered setup and no SQL-backed session state). The data is serialized and added to the page and must do roundtrips every request, adding to the total size of the page and making your site slower to load.
'<%# Control Language="C#" AutoEventWireup="true" CodeFile="HomePage.ascx.cs" Inherits="HomePage" %>
<script runat="server">
void testHF_ValueChanged(object sender, EventArgs e)
{
this.HFvalue.Text = this.testHF.Value ;
}
</script>
<asp:Label ID="UserNamelbl" runat="server" Text="User Name : " Visible="false"></asp:Label>
<asp:TextBox ID="UserNametxt" runat="server" Visible="false" ></asp:TextBox>
<asp:Label ID="HFvalue" Text="......" runat="server"></asp:Label>
<asp:HiddenField ID="testHF"
OnValueChanged="testHF_ValueChanged"
value=""
runat="server" ></asp:HiddenField>
<input type="submit" name="SubmitButton" value="Submit" onclick="CL()" />
<script type="text/javascript">
function CL()
{
this.testHF.Value = this.UserNametxt.Text;
}
</script>
'