All time working with ASP.NET I never really bothered about ViewState and how it works until today.
ViewState is cool and it works. It is stored as a hidden field inside the the form and posted back to the server. But for what reason is this information stored in a hidden field? Some people go about and write it to session, application, cache or even global static variables to get rid of it. My question is why do I need the ViewState variable/data itself?
Doesn't a page/form work like this?:
1.) I get my form which is empty at the beginning.
2.) I enter some data in there and do a postback via a button for instance.
3.) The page is reloaded with the values I entered automatically restored. ASP.NET has the values since they are posted via the form.
Why do it need to store them another time inside a hidden field? I just don't get it and have no idea why I would need that stuff in there. The data I need is posted and after posting I don't need what was in the fields the time before the post. I want the new values not the old ones. Or am I missing something?
Try this:http://msdn2.microsoft.com/en-us/library/ms972976.aspx
Hope that helps.
Aaron
The reason for view state is this: Say you fill out a form, submit it, and it displays a second page that says you have an error. If you click the back button and you have viewstate disabled, the fields are emtpy. If viewstate is enabled, the data is retained. It is a way of retaining the data on the client machine momentarily.
Hope this helps!
Nope that's not correct, it's got nothing to do with the back button - that's to do with your browsers own cached version of the page itself - it has nothing to do with Viewstate.
Here's a quick overview:
WhatViewState Isn't:
ViewState does not restore posted values to controls on a WebForm.
If you disable a control's ViewState, you will see that its value is still restored.
ViewState does not automatically recreate any controls that were dynamically created in the code.
Dynamically created controls on a page must be recreated when the page PostBack is processed.
ViewState is not for user or session data or for transferring data across pages.
Viewstate only can store data that is sent back to the same page during a PostBack operation.
ViewState does not hold "Controls".
Viewstate does not normally hold entire controls - only values and properties.
What ViewState is:
Viewstate represents thestate of the page when it was last processed on the server. ViewState is used to track and restore the state values of controls that would otherwise be lost, either because those valuesdo not post with the form or becausethey are not in the page html.A control defined solely in your page html with no changes made in thecode will have no ViewState. ViewState only holds the values ofproperties that are dynamically changed somehow, usually in code,data-binding, or user interactions, so that they can be restored oneach request. ViewSate does not hold "controls", it only hold valuesand the ID's of the controls they belong to.
JoshStodola:
The reason for view state is this: Say you fill out a form, submit it, and it displays a second page that says you have an error. If you click the back button and you have viewstate disabled, the fields are emtpy. If viewstate is enabled, the data is retained. It is a way of retaining the data on the client machine momentarily.
Hope this helps!
For correct view state understanding, please visit the link below
Understanding ViewState
HC
Wow, Mr.B!
Why don't you post a link to Peter Bromberg's explanation instead of try to take credit for it.
Because:
a) it's one extra link - I hate people who post solutions which involve clicking on a link to THEN find the information.
b) I don't want to take credit for it - I just wanted the question answered correctly, rather than answered incorrectly.
For those that care, here is the link to the original article:
http://www.eggheadcafe.com/articles/20060208.asp
No need to take offence just because you got something wrong!
First of all, that is a published article with a copyright statement at the bottom of the page. Why would you copy and paste the contents without at least giving credit to the source? Because you wanted to take credit for it. Have some respect!
I have already posted the link to the original article, get off your high horse and get back to providing incorrect answers to people's questions.
Nope that's not correct, it's got nothing to do with the back button - that's to do with your browsers own cached version of the page itself - it has nothing to do with Viewstate.
Here's a quick overview:
WhatViewState Isn't:
ViewState does not restore posted values to controls on a WebForm.
If you disable a control's ViewState, you will see that its value is still restored.ViewState does not automatically recreate any controls that were dynamically created in the code.
Dynamically created controls on a page must be recreated when the page PostBack is processed.ViewState is not for user or session data or for transferring data across pages.
Viewstate only can store data that is sent back to the same page during a PostBack operation.ViewState does not hold "Controls".
Viewstate does not normally hold entire controls - only values and properties.What ViewState is:
Viewstate represents thestate of the page when it was last processed on the server. ViewState is used to track and restore the state values of controls that would otherwise be lost, either because those valuesdo not post with the form or becausethey are not in the page html.A control defined solely in your page html with no changes made in thecode will have no ViewState. ViewState only holds the values ofproperties that are dynamically changed somehow, usually in code,data-binding, or user interactions, so that they can be restored oneach request. ViewSate does not hold "controls", it only hold valuesand the ID's of the controls they belong to.
Sadly, and much as I rate Peter's work, there are some minor errors of fact in his article.
For example, the statement "A control defined solely in your page html with no changes made in thecode will have no ViewState." is tragically flawed (unless, by control, you mean non-server side html element, which won't use ViewState anyway as it has no server-side presence). Here's why.
A boring, plain old asp:TextBox uses ViewState to determine whether it should raise its TextChanged event on the server. It works thus:
1. During render, it spits out the current value of the control as part of the standard <input> element; also, it saves the current value of the control into ViewState.
2. On post back, it initialises the value of the control to the value read from ViewState. It then reads the value of the form variable for the relevant <input> element. It compares the values. If they are different, the control will raise its TextChanged event.
As you can see, this usage of ViewState occurs even if the control is not manipulated in any way in code, data binding or (and I can't see how this can apply to a server-side control anyway) as a result of user interaction.
Understanding this ViewState behaviour is important. For example, with ViewState disabled, the TextBox will raise the TextChanged event every time a form is posted back with a value that is different from that set initially in the server-side page,even if the user has not changed it during a specific round-trip sequence. With ViewState enabled, the TextChanged event is only raised after a round trip with the client where the user actually changed the text. Most, if not all, of the server-side controls adopt this behaviour for their server-sidexxxChanged events, and it's one of the reasons why you should not perform any significant coding in thexxxChanged event handlers.
Similarly, ViewState can be used to transfer state across pages in the case where cross-page postbacks are being used. Arguably, this would have to be considered a fragile design, but it does work nevertheless.
Peter's summary, and the Paul Wilson article from which it clearly derives, are both really good explanations but like all such summaries, (potentially) important information is sometimes dropped for brevity. Therefore, take care assuming that they represent definitive explanations.
Thank you DMW! That thing with the Event raised made things totally clear to me now.
0 comments:
Post a Comment