The Usesubmitbehavior property of the ASP. NET button control is causing a massacre

First of all, let's not say what the Usesubmitbehavior attribute on the title is, let's say the following.

Usually, when we write a form page, there are two buttons at the bottom of the word "submit" and "return". As the name implies, they all know the function, but in general we will add some validation to the contents of the form, so there is a problem. Because two buttons are server controls (with the runat= "Server" property), the button is validated first (whether you use the foreground jquery.validate validation or ASP. NET-brought validation of the background validation control). For the "Submit" button, this is really what we want, but for the "back" button, we don't want this to happen, but instead we want it to go straight to the previous page without being validated.

In this case, my previous solution was to

<asp:button id= "Button_back" runat= "Server" text= "Back" onclick= "Button_back_click"/>

Into

<input type= "button" value= "Back" onclick= "backtopage ();"/>

This form. The Backtopage method implements the page jump.

I'm sure a lot of friends write this, right? It's OK to solve the problem anyway. why not? look down.

But today, inadvertently discovered the Button.usesubmitbehavior attribute, set it to false, will make the "Back" button "Dodge" off the form verification, directly execute the method in the Click event. That's what we always wanted, wasn't it? And the button is also very uniform, do not have to add additional JS code.

here to illustrate , we do not think that button.usesubmitbehavior is really used to "dodge" verification, I just use this word to express the effect of its implementation. In fact, the Button control has a specific property that is used to mask the validation control. is button.causesvalidation, by name we should be able to understand one or two.

Then you will not ask, "since there is this attribute, the above problem is not a problem, can be easily solved." ”

I want to say, "That's it!" "But only if you have background validation in your project. But in reality, I don't think everyone's going to do it. Anyway, I'm pretty used to using jquery.validate to verify the plug-in (foreground validation). Then let's go on to study Button.usesubmitbehavior .

Look at an example:

Front 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

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/44/CF/wKioL1Pi2hTT2wOhAABtt6ip0kE748.jpg "title=" Qq20140805173159.jpg "alt=" Wkiol1pi2htt2wohaabtt6ip0ke748.jpg "/>

Front Code:

<asp:button id= "button_confirm" runat= "Server" text= "OK"/><asp:button id= "Button_back" runat= "Server" Text= "Return" usesubmitbehavior= "false" onclick= "Button_back_click"/>

View the form in the source code in the browser

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/44/CF/wKiom1Pi2R7BpJwMAACQzy-l3C8380.jpg "title=" Qq20140805173349.jpg "alt=" Wkiom1pi2r7bpjwmaacqzy-l3c8380.jpg "/>

As you can see, after adding the usesubmitbehavior attribute, the parsed HTML statement is significantly different. It dawned on me that when you add the usesubmitbehavior property, the Type property becomes a button, which is the same as the previous workaround, because it is not a submit property. So there is no way to trigger the validation of jquery.validate (the answer to the above orange-bold section). This is why it is not necessary to verify the foreground after Usesubmitbehavior is set to false. That's the answer.

But is it a little weird to end up here? We have used a new attribute to achieve our purpose, but the significance of this attribute is not to achieve our purpose.

To tidy up your thoughts, we need to erase them from our heads. The Usesubmitbehavior property does not have anything to do with whether or not to contact the publish order validation. Let's focus on this property itself, after all this is the title.

I checked the MSDN.

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/44/CF/wKioL1Pi2l7gYYgNAANl8QOMIFs559.jpg "title=" Qq20140805154844.jpg "alt=" Wkiol1pi2l7gyygnaanl8qomifs559.jpg "/>

It can be seen that the focus is on the two mechanisms these drawings points out:

1, the client browser submission mechanism

2, ASP. NET postback mechanism

Explain, if there is something wrong, please correct me.

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

Is that the browser encapsulates a request message to the server, the server parses the message, reorganizes it, generates a response message, sends it back to the browser, and then parses it after the browser receives it, generating the pages we see and the data we don't see. The communication between them is in accordance with the HTTP protocol.

Emphasis is placed on: HTTP is a stateless protocol, which means that every time the browser requests, the server response is completely new.

2, we can look at this link said content: http://blog.sina.com.cn/s/blog_7815564501012qgy.html for the postback mechanism, I hope you can follow the steps in this article to write a small demo to try, will feel more.

Postback mechanism, is to request their own page, this mechanism, if you understand the mechanism, you will find that the ASP is a little deviation from the back, the previous is stateless, this one is able to save the previous value, as the next time the initial page.

As a practical example , when we fill out a form, there are a lot of items, but when we fill in the second-to-last item, accidentally clicked on the refresh, normal to the first mechanism, the form controls on the value should be completely emptied, because at this time there is no database read operation, So the page can not have a value, but with a postback mechanism, __viewstate to save the page down, so that the preservation of our previous fill in the content. But a friend in the tech group said, "Now this stuff is rarely used, and it's basically not going to be a project development with controls." "囧rz Ah ~ I have been using the joy, how to break?"

Two mechanisms explained, maybe we still a little confused, in fact, I am the same. Write a demo below to make the whole thing clearer, borrow the Fiddler tool.

Page Show:

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/44/CF/wKioL1Pi2quhBKOLAABg4-bnKE4605.jpg "title=" Qq20140806164824.jpg "alt=" Wkiol1pi2quhbkolaabg4-bnke4605.jpg "/>

HTML code:

Page Source:
650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/44/CF/wKiom1Pi2cDD31CeAAC8pU5WYJw462.jpg "title=" Qq20140806165337.jpg "alt=" Wkiom1pi2cdd31ceaac8pu5wyjw462.jpg "/>
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";         }    }
Operation Steps:
1. Initial page
650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/44/CF/wKiom1Pi2enQatSSAAAvoqIGKTo747.jpg "title=" Qq20140806170706.jpg "alt=" Wkiom1pi2enqatssaaavoqigkto747.jpg "/>
2. Click the Browser-server button three times in a row first.
650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M02/44/CF/wKioL1Pi2xWTD8M1AACzZRdAx9o398.jpg "style=" float: none; "title=" qq20140806170910.jpg "alt=" Wkiol1pi2xwtd8m1aaczzrdax9o398.jpg "/>
650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M00/44/CF/wKiom1Pi2gmzyv2PAAWe90Ja6eA270.jpg "style=" float: none; "title=" qq20140806171124.jpg "alt=" Wkiom1pi2gmzyv2paawe90ja6ea270.jpg "/>

3, then connect click postback button three times.
650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M00/44/CF/wKiom1Pi2jGiU24YAADNHNoTOZg045.jpg "style=" float: none; "title=" qq20140806171218.jpg "alt=" Wkiom1pi2jgiu24yaadnhnotozg045.jpg "/>
650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M02/44/CF/wKiom1Pi2kXgW4RoAAXkBwyh6JI797.jpg "style=" float: none; "title=" qq20140806171521.jpg "alt=" Wkiom1pi2kxgw4roaaxkbwyh6ji797.jpg "/>

With this demo example, if we look at the page from the view, we can not see the difference between the two, because the background would like to implement the function of both (just click the button, will go through the Page_Load method, and then through the individual click event, to the text box and two buttons to append content). However, using the Fiddler tool, we will find that the submitted form content is indeed somewhat different, when theUsesubmitbehavior property is set to False when the button commits itself, it is not passed to the server side as a parameter of the form.
Is that the only difference? The feeling is not enough, but I really can't write.
Interested friends can think of other examples of comparison, such as try to add enableviewstate= "false" on the page to see what effect the button will be. I have tried this, but I still can't prove anything.
Ah, finally think of a, you can give the Browser-server button plus enableviewstate= "false" property, um, this is more reliable, to Browser-server button plus  Enableviewstate= the "false" property so that it has no postback mechanism, because the ASP. NET control has a postback mechanism by default, so that the Browser-server button has only a simple client-browser commit mechanism, The postback button only has a postback mechanism. Page effect is very obvious ah ~
Sell a Xiaoguanzi, want to see the effect of the friend himself to try it, we can message to do exchanges, forgive me, this article is a bit tired of the truth.
Summing up,usesubmitbehavior This attribute is absolutely can be said to be non-mainstream, take the time to study will be very egg ache?
In fact, I never thought this article would be written so long, but as I studied this attribute in depth, I learned about the underlying interaction principles of ASP, the ASP. NET page life cycle, the postback mechanism, and the validation related issues. To tell the truth, the harvest is quite much, but also very happy. Of course, we should continue to practice and study.
This article is from the "Give Me a Gener cigarette" blog, please be sure to keep this source http://zhouhongyu1989.blog.51cto.com/2931598/1536727