The case that is caused by the UseSubmitBehavior attribute of the ASP. NET Button control,

The case that is caused by the UseSubmitBehavior attribute of the ASP. NET Button control,

Here we will not talk about the UseSubmitBehavior attribute on the title, but the following situation first.

Usually, when we write a form page, there are two buttons at the bottom: "Submit" and "return. As the name suggests, they all know their functions, but in general we will add some verification to the content of the form, so there is a problem. Because the two buttons are Server controls (with the runat = "Server" attribute), the button will be verified first after you click the button (whether you use jQuery at the front end here. validate verification or ASP. NET comes with the background verification control verification, will first verify ). For the "Submit" button, this is indeed what we want, but for the "return" button, we do not want this situation, but want it to jump back to the previous page without verification.

In this case, my previous solution is

<asp:Button ID="button_back" runat="server" Text="back" OnClick="button_back_Click" />

Change

<input type="button" value="back" onclick="BackToPage();" />

This form. The BackToPage method redirects the page.

I believe many of my friends write this? You can solve the problem.Why?Look down.

However, we accidentally discovered the property "Button. UseSubmitBehavior" today and set it to "false". This will cause the "return" Button to "escape" Form Verification and directly execute the method in the click event. This is exactly what we always wanted, isn't it? In addition, the buttons are very uniform and no additional js code is required.

It should be noted that we should not think that Button. UseSubmitBehavior is really used to "escape" verification. I just use this word to express the effect it achieves. In fact, the Button control has special properties to block verification controls. That is, Button. CausesValidation. We should be able to understand one or two by name.

Would you ask, "since this attribute exists, the above problems are not a problem and can be easily solved ."

I want to say, "That's it !" The premise is that only background verification exists in your project. But in reality, I don't think everyone will do this, right? Anyway, I am quite used to using jQuery. validate to verify the plug-in (front-end verification ). Let's continue to study Button. UseSubmitBehavior.

Let's look at an example:

Front-end code:

<Asp: Button ID = "button_confirm" runat = "server" Text = "OK"/> <asp: button ID = "button_back" runat = "server" Text = "return" onclick = "button_back_Click"/>

View the form in the source code in the browser

Front-end code:

<Asp: Button ID = "button_confirm" runat = "server" Text = "OK"/> <asp: button ID = "button_back" runat = "server" Text = "back to" UseSubmitBehavior = "false" onclick = "button_back_Click"/>

View the form in the source code in the browser

We can see that after the UseSubmitBehavior attribute is added, the html statements parsed are obviously different. When I saw this, I suddenly realized that when the UseSubmitBehavior attribute was added, the type attribute became a button, which is the same as the previous solution, because it is not a submit attribute, therefore, jQuery will not be triggered. validate verification method (answer the question of the orange bold part above ). This is why foreground verification is not required after UseSubmitBehavior is set to false. This is the answer.

But will it be a bit strange when it's over? We use a new attribute for our purpose, but this attribute does not exist for our purpose.

Sort out your thoughts. The above example needs to be erased from your head. The UseSubmitBehavior attribute has nothing to do with whether to trigger form verification. Let's focus on the attribute itself. After all, this is the title.

I checked MSDN.

We can see that the focus is the two mechanisms pointed out by the supervisor:

1. client browser Submission mechanism

2. ASP. NET sending back Mechanism

Please correct the errors.

1, you can see the first part of this link: http://www.th7.cn/Program/net/201309/150415.shtml

That is, the browser will encapsulate a request packet and send it to the server. The server will parse the packet, reorganize it, generate a response packet, and send it back to the browser. The browser will parse it after receiving the packet, the webpage we see and some data we don't see are generated. Communication between them is based on the HTTP protocol.

Emphasis:HTTP is a stateless protocol. That is to say, each browser request and server response are completely new.

2, you can see the content of this link: http://blog.sina.com.cn/s/blog_7815564501012qgy.html for the sending back mechanism, I hope you can follow the steps described in this article to write a small Demo try, will have a more feeling.

The sending-back mechanism is to request your own page. This mechanism is more involved. If you understand the previous mechanism, you will find ASP. the NET re-sending mechanism is a little different from the Mechanism. The previous one is stateless. This one can save the previous value as the initial value of the next page.

For exampleThat is, when we fill out a form, there are many items, but when we fill in the second to last item, we accidentally click to refresh. Normally, according to the first mechanism, the values on the controls in the form should be cleared, because no database read operation is performed at this time, so the page cannot have values, but with the sending back mechanism, __viewstate saves the page so that the previously entered content is retained. However, a friend in the Technical Group said, "This is rarely used now, and controls are basically not used for project development ." Why rz ~ I have been using it all the time. Why?

After explaining the two mechanisms, you may still be confused. In fact, the same is true for me. Let's write a Demo to make the whole thing clearer. Use the Fiddler tool.

Page display:

Html code:

Page source code:

Background code:
    public partial class WebForm1 : System.Web.UI.Page    {        protected void Page_Load(object sender, EventArgs e)        {            textbox_content.Text += "M";        }        protected void button_usesubmitbehavior_true_Click(object sender, EventArgs e)        {            textbox_content.Text += "true";            button_usesubmitbehavior_true.Text += "1";            button_usesubmitbehavior_false.Text += "2";        }        protected void button_usesubmitbehavior_false_Click(object sender, EventArgs e)        {            textbox_content.Text += "false";            button_usesubmitbehavior_true.Text += "3";            button_usesubmitbehavior_false.Text += "4";        }    }

Procedure:
1. Initial page

2. Click the browser-server button three times in a row.

 
3. Connect again and click the postback button three times.

 
In this demo, if we look at the page display, we can't see the difference between the two, because the functions to be implemented in the background are both implemented (that is, click the button, it passes through the page_load method once and then through the respective click events to Append content to the text box and two buttons ). However, using the fiddler tool, we will find that the content of the submitted form is indeed somewhat different. When a button with the UseSubmitBehavior attribute set to false is submitted, it is not passed as a form parameter to the server.
Is this the only difference? I don't feel enough, but I can't write it.
If you are interested, you can think about other comparison examples. For example, try to add the EnableViewState = "false" attribute to the page to see what the effect will be after you click the button. I also tried this, But I still cannot prove anything.
Ah, I finally thought of one. You can add the EnableViewState = "false" attribute to the browser-server button. Well, this is reliable, add the EnableViewState = "false" attribute to the browser-server button to prevent sending back because Asp. by default, the browser-server button only has the submit mechanism of the client browser, and the postback button only has the send-back mechanism. The page effect is abnormal ~
If you want to see the results, please give it a try. You can leave a message for communication. Forgive me. This article is a bit tiring.
To sum up, UseSubmitBehavior is definitely a non-mainstream attribute. Will it hurt to spend time researching it?
In fact, I never thought that this article would be written so long at first, but with the in-depth study of this attribute, I learned ASP. NET underlying interaction principle, ASP.. NET page lifecycle, sending-back mechanism, and verification problems. To be honest, I am very happy to have gained a lot. Of course, you must continue to practice and learn.
 
Attachment link: http://files.cnblogs.com/zhouhongyu1989/UseSubmitBehavior%E7%A4%BA%E4%BE%8BDemo.rar

Button problems in aspnet
Usually hide the role of placing an asp: button because of the webform postback mechanism, you cannot directly submit the page

Because webform is an event mechanism, we will hide an asp: button

For example, in such a common scenario, a button is required to trigger a pop-up box or a pop-up page of div + iframe, click "OK" to return a selected user ID and the like into a hidden domain. In this case, you need to trigger the server event, so you have to use the hidden asp: button, if it is easy to do, you only need to use document. getElementById ('buttonid '). click (); then the server event is triggered.

If this is not done, the webform mechanism cannot be used, but the current mvc mechanism does not need to be used.

Does the aspnet button control have an onmouse event?
Because the Button is a server-side control, there is no onmouse series event, because it is impossible to trigger events that can only be triggered by the client on the server side. (Jump as soon as you move the mouse up. It's impossible)

Client events can be specified in the post code or directly after the Button label declaration. It's just that there are no smart prompts.

Post Code:
Button. Attributes. Add ("onmouseover", "alert ('move the mouse up! ')");