Notes to self...
PRESERVING STATE
The http protocol is stateless. You can preserve state at the 1)page level, 2)session level, 3)application level.
Typically a user will request, submit, and resubmit pages, and each time it's state changes. User today expect that any data they enter on the form will persist accross those requests.
If you type in a textbox and submit, the textbox will be empty when the page will return, unless the data is presreved.
In classic asp, data had to be preserved manualy for each control in a request and response object, .net simplifies that by automatically preserving the state of all input controls on the form.
DYNAMIC PAGE MODIFICATION MADE POSSIBLE BY THE ADDITION OF THE VIEWSTATE CONTROL
It also preserves information about different states of information that the page was in when it was sent to the browser(orignal state).. Therefore the hidden VIEWSTATE control contains an encoded representation of all non-default proprety setting.
Viewstate is enabled from the corresponding property of the form object. It can be also viewed in aspx page as the enableviewstate attribute of the form element. Even if you choose to disable it, a small version of it will still be visible in the html page since once it's rendered on the client. This is because asp.net itself uses it to carry small amounts of information.
In summary, this hidden text box that is the viewstate is one of the ways that can be used to persist state between postbacks of a page.
VIEWSTATE AND PAGE LIFECYCLE
1.Page is constructed based on the default properties
2.Property values stored int he view state are applied.
3.Page and control event handlers run; possibly making modification, possibly making further modifications to the controls within the page.
4.Final page state is encoded in a hidden ViewState control
5.Page sent to client
It therefore stores the original values before the user gets to modify them, and will keep them after the client sends his request, in order to compare original/modified. To summarize, after it's sent to the client then sent back to the server, viewstate can compare postback values with the original values to see if events need to be raised or can be skipped.
So asp.net Event handlers run in response to changes the user made to the page.
<br />
The viewstate is encoded in base64 format, and all controls who have EnableViewState property to true are included in it.It encapsulates teh state of the form after it's rendered, before it's sent to the user.
It is not always required to preserve all data. Sometimes controls will remember state, since HTML form automaticaly embeds teh values of them in when POSTed.
When the user changes the value of a control, asp.net uses the viewstate to compare it to it's original value, if it's value has changed, asp.net raises events based on that. For example, if the text of the textbox has changed, the TextBoxChanged event is fired; if the nableViewState property is enabled. If it's disabled, asp.net fires the event for this control on every postback, this is a side effect of disabling viewState, especialy if you have server side code for this event.
It is common practice to store data in your own hidden controls.
ADVANTAGES OF USING VIEWSTATE OVER CUSTOM HIDDEN CONTROLS
There are advantages of using viewstate over your own hidden control. 1)the data is encoded 2) object based interface for using viewstate property 3)collection of statebag obejects that contain the values in the viewstate, ViewState["MyItemName"] = myObject; and read it like myObject = ViewState["MyItemName"].
For the value to be available in viewstate, the object has to be serializable, just adding the [Serrializable()] attribute to your class is all you need to to.
You likely don't need view state if you arent handling change events, or if your code doesnt modify the page progressively between postbacks.
You can improve the perfomance of your site by leaving controls out of view state(disabling it for the givent control), as long as the viewstate is not essential to the proper fonctionality of the control. Since 2.0, the
control state preserved in view state now hold any information critical to the proper fonctionnality of the control.
If you want to see the content of the viewstate string, Base-64 and can easily be decoded. You can encrypt the viewstate so that it can't be decoded as easily by setting the attribute <%@Page ViewStateEncryptionMode="Always" in the page directive or in the web.config with, in the web.config it would ecnrypt all the pages of the application, at a performance cost since asp.net puts a hash value in the viewstate that it compares against. Even without encryption the state is protected by the default followiong attribute set to true, EnableviewStateMac. In a web farm, it might be practcal to share the key between servers as you can then share the viewstate between servers, allowing consecutive requests to be handled by different servers in the farm.
PAGE LEVEL STATE LIMITATIONS
1)Can't store too much data(it can easily grow to megabytes, and transfering megabytes slows down performance)
2)Can't access outide the page(viewState applies just to a single page that is being posted back to itself, if you need to do that, you need something else than viewstate)
3)can't preserve data outside postbacks(so if you navigate to another page, you've lost the viewstate data, if you need to do that, you need something else than viewstate)
COOKIES AND CROSS PAGE POSTING
If you have ot post accross pages, cookies can be used, and also Cross Page Posting by setting the PostBackURL property of a button, then the POST request is directed at the specified page, and you can get the values from the PreviousPage property of the next page
PRESERVING STATE
The http protocol is stateless. You can preserve state at the 1)page level, 2)session level, 3)application level.
Typically a user will request, submit, and resubmit pages, and each time it's state changes. User today expect that any data they enter on the form will persist accross those requests.
If you type in a textbox and submit, the textbox will be empty when the page will return, unless the data is presreved.
In classic asp, data had to be preserved manualy for each control in a request and response object, .net simplifies that by automatically preserving the state of all input controls on the form.
DYNAMIC PAGE MODIFICATION MADE POSSIBLE BY THE ADDITION OF THE VIEWSTATE CONTROL
It also preserves information about different states of information that the page was in when it was sent to the browser(orignal state).. Therefore the hidden VIEWSTATE control contains an encoded representation of all non-default proprety setting.
Viewstate is enabled from the corresponding property of the form object. It can be also viewed in aspx page as the enableviewstate attribute of the form element. Even if you choose to disable it, a small version of it will still be visible in the html page since once it's rendered on the client. This is because asp.net itself uses it to carry small amounts of information.
In summary, this hidden text box that is the viewstate is one of the ways that can be used to persist state between postbacks of a page.
VIEWSTATE AND PAGE LIFECYCLE
1.Page is constructed based on the default properties
2.Property values stored int he view state are applied.
3.Page and control event handlers run; possibly making modification, possibly making further modifications to the controls within the page.
4.Final page state is encoded in a hidden ViewState control
5.Page sent to client
It therefore stores the original values before the user gets to modify them, and will keep them after the client sends his request, in order to compare original/modified. To summarize, after it's sent to the client then sent back to the server, viewstate can compare postback values with the original values to see if events need to be raised or can be skipped.
So asp.net Event handlers run in response to changes the user made to the page.
<br />
The viewstate is encoded in base64 format, and all controls who have EnableViewState property to true are included in it.It encapsulates teh state of the form after it's rendered, before it's sent to the user.
It is not always required to preserve all data. Sometimes controls will remember state, since HTML form automaticaly embeds teh values of them in when POSTed.
When the user changes the value of a control, asp.net uses the viewstate to compare it to it's original value, if it's value has changed, asp.net raises events based on that. For example, if the text of the textbox has changed, the TextBoxChanged event is fired; if the nableViewState property is enabled. If it's disabled, asp.net fires the event for this control on every postback, this is a side effect of disabling viewState, especialy if you have server side code for this event.
It is common practice to store data in your own hidden controls.
ADVANTAGES OF USING VIEWSTATE OVER CUSTOM HIDDEN CONTROLS
There are advantages of using viewstate over your own hidden control. 1)the data is encoded 2) object based interface for using viewstate property 3)collection of statebag obejects that contain the values in the viewstate, ViewState["MyItemName"] = myObject; and read it like myObject = ViewState["MyItemName"].
For the value to be available in viewstate, the object has to be serializable, just adding the [Serrializable()] attribute to your class is all you need to to.
You likely don't need view state if you arent handling change events, or if your code doesnt modify the page progressively between postbacks.
You can improve the perfomance of your site by leaving controls out of view state(disabling it for the givent control), as long as the viewstate is not essential to the proper fonctionality of the control. Since 2.0, the
control state preserved in view state now hold any information critical to the proper fonctionnality of the control.
If you want to see the content of the viewstate string, Base-64 and can easily be decoded. You can encrypt the viewstate so that it can't be decoded as easily by setting the attribute <%@Page ViewStateEncryptionMode="Always" in the page directive or in the web.config with
PAGE LEVEL STATE LIMITATIONS
1)Can't store too much data(it can easily grow to megabytes, and transfering megabytes slows down performance)
2)Can't access outide the page(viewState applies just to a single page that is being posted back to itself, if you need to do that, you need something else than viewstate)
3)can't preserve data outside postbacks(so if you navigate to another page, you've lost the viewstate data, if you need to do that, you need something else than viewstate)
COOKIES AND CROSS PAGE POSTING
If you have ot post accross pages, cookies can be used, and also Cross Page Posting by setting the PostBackURL property of a button, then the POST request is directed at the specified page, and you can get the values from the PreviousPage property of the next page
Comments
Post a Comment