In-depth explanation of property persistence of controls (1)
SeriesArticleLink:
ASP. NET custom control component development chapter 1 to be continued
ASP. NET custom control component development chapter 1 Article 2 to be continued
ASP. NET custom control component development chapter 1 Article 3
ASP. NET custom control component development chapter 2 inherit the custom control of webcontrol
ASP. NET custom control component development chapter 3 add events to controls
ASP. NET custom control component development chapter 3 after adding events to controls
ASP. NET custom control component development chapter 4 compositecontrol
ASP. NET custom control component development chapter 4 compositecontrol for compositecontrol
ASP. NET custom control component development chapter 5 template control development
ASP. net2.0 custom control component development chapter 6 in-depth introduction to control attributes
ASP. net2.0 widget Development Video initial experience
Since I wrote an article on control development, I have received many emails from my friends and raised many questions. Thank you for your attention. Let's talk about some questions today.
Answer the question.
Although I am developing controls in this series, I hope you can have a better understanding of ASP. NET more quickly by developing controls.
We also need to clarify some basic things.
For the purpose of in-depth explanation of attributes, I will first talk about the page cycle and page resolution problems:
1. Page parsing:
It may be said that when pages are submitted to the server, they are parsed into inheritance and page classes. The most direct proof is:
Code
<% @ Page Language = " C # " Autoeventwireup = " True " Codefile = " Default. aspx. CS " Inherits = " _ Default " %>
Let's take a look.CodeHide
Code
Codefile="Default. aspx. CS"Inherits="_ Default"
You may be confused: An ASPX page contains some Markup languages, such as the following: (Note: Resolve the following text to a class)
Code
<% @ Page Language = " C # " Autoeventwireup = " True " Codefile = " Default. aspx. CS " Inherits = " _ Default " %>
<!Doctype HTML public"-// W3C // dtd xhtml 1.0 transitional // en" "Http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
< HTML xmlns = " Http://www.w3.org/1999/xhtml " >
< Head runat = " Server " >
< Title > No title page </ Title >
</ Head >
< Body >
< Form ID = " Form1 " Runat = " Server " >
< Div >
< ASP: button ID = " Button1 " Runat = " Server " Text = " Submit " Onclick = " Button#click " /> </ Div >
< ASP: linkbutton ID = " Linkbutton1 " Runat = " Server " > Linkbutton </ ASP: linkbutton >
</ Form >
</ Body >
</ Html >
As you may see, the above source is a document similar to XML.
After this page is sent to the server, the server will use the regular expression mode to parse this document. For example, if you see "
Literalcontrol, such as: literalcontrol head = new literalcontrol ("
In this way, a document similar to XML is parsed to a CS class inherited from page. As follows: (the pseudo code is just a demonstration, but it is not like this ):
Code
Public Class Default_aspx: Page
{
// .,
Htmlform = New Htmlform ();
button button1 = New button ();
buton1.text = " submit " ;< br> button1.click += button#click ( Object sender, eventargs E);
// .
//.
}
Note: During page parsing, the values we set for the control, such as text = "Submit", are initialized to the control.
Then, an instance of the class is generated for the parsed class, And the lifecycle of the page starts.
2. Http Working Mode
HTTP is a stateless connection mode. In other words, after a client sends a job request to a server like a server, the server no longer maintains the client information after the server responds.
3. Explanation of attribute persistence
It is assumed that there is no property persistence in the button. Let's take a look at the following process:
3.1: put a button on the page, set the text attribute to "Submit", and then write down the following in the Click Event of the button:
Code:
Code
Protected Void Button#click ( Object Sender, eventargs E)
{
If ( This . Button1.text = " Submit " )
This . Button1.text = " Clear " ;
Else
This . Button1.text = " Submit " ;
}
3.2: Submit the page to the server. At this time, the page resolution is started, and the text attribute of the button is set
"Submit", and then the lifecycle of the page starts. The last page is displayed in front of us.
3.3: click the button on the browser page to submit the page to the server again. The page starts parsing and starts the lifecycle.
In a certain stage (explained later), The Click Event of the button is triggered, the text of the button is set to "empty", and the page is displayed in front of us.
3.4; when we click the button again, we originally wanted to make the button display "Submit", but no matter how many times we click it, the button always displays "clear".
Why?
Because each time the page is submitted, the page parsing result sets the text attribute of the button as "Submit". When the button is clicked for the second time
The text property displays "clear", but once the page is submitted, the page is parsed as it was for the first time and initialized. The click event of the button still finds that the text of the button is "submitted". Because after the last submission, the text attribute of the button-"clear" is not saved (based on HTTP protocol ).
So we can develop it like winform and achieve the desired effect. ASP. NET adopts the "Save status" technology.
4. Save status Technology
In fact, it is also very simple, but every time the page is returned, the status of all settings of the last page is saved in a form string "_ viewstate", which is like this, when the page returns to the client, the server serializes the status of the control in the page into a string,
Send it to the client together. After the client submits the page, the server parses the submitted _ viewstate and deserializes it.
If the status of each control is restored, the status of the last page is displayed.
Then, in the lifecycle of the page, if there is code to modify the control status in the control event, it is triggered at the appropriate time, and then the value of _ viewstate is updated again.
In this way, the control property persistence is complete.
Therefore, when developing custom controls, we often need to display the persistence of the lifecycle control attributes. Viewstate is used.