Maximizing.ASP.dot.NET.Real.World.ObjectOriented.Development [Electronic resources] نسخه متنی

The Postback Process

Let's look at the postback process in detail so you can see how ASP.NET makes the stateless Web appear to have state, similar to the way a Windows application works.

The basic way to send any data from a Web page is via the HTML form element. Every ASP.NET Web form has a form element. When you write the page, you include the runat="server" attribute. It's rendered in the final page, as shown in Listing 7.2.

Listing 7.2. The rendered form tag in a Web form

<form method="post" action="Default.aspx" onsubmit="javascript
:return WebForm_OnSubmit();"
 id="form1">

You're familiar with most of these attributes from your HTML 101 days. The post method is the HTTP way of sending form data, the action attribute says where to post the data to (the same page we're viewing, including any query string information), and the ID identifies the form by name. There's also a JavaScript onsubmit attribute, which will contain different things depending on what kind of controls you have loaded on the page. It may call any number of functions embedded in the page or external scripts that perform form validation or other control-specific actions.

Next you'll find several hidden form fields used to store data that we'll send back to the server on postback, as shown in Listing 7.3. You already know about the __VIEWSTATE field. The other two are used to pass along two pieces of data: __EVENTTARGET and __EVENTARGUMENT. You'll notice that these values are empty, but they won't be for long.

Listing 7.3. The hidden form fields

<input type="hidden" name="__EVENTTARGET" value=" />
<input type="hidden" name="__EVENTARGUMENT" value=" />
<input type="hidden" name="__VIEWSTATE" value="
/wEPDwUKMTE2MjI0Mzc0MQ9kFgICAw9kFgICAw8UKwANDxYIHgh
EYXRhS2V5cxYAHgtfIUl0ZW1Db3VudAL////
/Dx4JUGFnZUNvdW50AgEeFV8hRGF0YVNvdXJjZUl0ZW1Db3VudAL////
/D2RkZGRkZGRkZGRkZGRkGAEFHl9fQ29udHJvbHNSZXF1aXJlUG9zdEJhY2tLZXlfXxY
CBRFMb2dpbjEkUmVtZW1iZXJNZQUSTG9naW4xJEltYWd
lQnV0dG9uKI3dzTLbZM2g4Pn/ZFiCcm7ffag="
 />

The three hidden fields act as messengers to the server to help it understand what to do. With our Windows application analogy, it's just a matter of checking memory to see what action took place and how to deal with it. With our ASP.NET application, we can determine this with three pieces of information. The first is the state of the controls when we first sent the page to the browser. We already covered the fact that __VIEWSTATE contains this information. The second bit of information we need is the event target of the postback, which is generally the name of the control that caused it. The last piece of data is the argument of the event, which might indicate some other information to aid in the processing of the postback.

Naturally we'll need some way to get values into the __EVENTTARGET and __EVENTARGUMENT fields before sending the form data back to the server. This is accomplished through a short JavaScript function rendered automatically in the page, as shown in Listing 7.4.

Listing 7.4. The doPostBack client-side script

<script type="text/javascript">
<!--
var theForm = document.forms['form1'];
function __doPostBack(eventTarget, eventArgument) {
if (theForm.onsubmit == null || theForm.onsubmit()) {
theForm.__EVENTTARGET.value = eventTarget;
theForm.__EVENTARGUMENT.value = eventArgument;
theForm.submit();
}
}
// -->
</script>

The script is fairly straightforward; it takes two parameters and assigns their values to the hidden __EVENTTARGET and __EVENTARGUMENT fields and then submits the form. The server now has all the information it needs to determine what happened on the client and what corresponding action to take. You don't have to worry about what exactly is going on in the round trip; you only must ensure that you have appropriate event handlers to respond to the changes in the form's state.

Different server controls do different things, and as such, you'll find a variety of different data items that need to be passed back to the server. Some controls render additional client-side script to handle validation or other functions before posting back. To keep it simple, let's take a LinkButton as an example. Listing 7.5 shows how you would write the control in the page, as well as how it would render in the browser.

Listing 7.5. A LinkButton in your page and in the rendered output

The LinkButton in the .aspx page

[View full width]

<asp:LinkButton ID="LinkButton1" Runat="server" OnClick="SomeHandler">LinkButton</asp
:LinkButton>

The LinkButton in the rendered HTML sent to the browser

<a id="LinkButton1" href="'LinkButton1','')">LinkButton</a>

In your page, you've declared the LinkButton with a name and specified the OnClick attribute to fire a method in your code called SomeHandler. When the user clicks on this button, you can see that the HRef attribute calls the automatically generated __doPostBack JavaScript function (from Listing 7.4), passing the button's name (LinkButton1) and a blank value to the function. The function copies the name of the button to the hidden __EVENTTARGET field and a blank string to the hidden __EVENTARGUMENT field. As the final step, the function submits the form to the server.

When the server gets the request from the browser, it sees that the __EVENTTARGET field has a value of LinkButton1. That can only mean that the __doPostBack Javascript function was called by LinkButton1, and the server should check to see what that control is supposed to do. It sees that the button was clicked (because that's all you can really do to a LinkButton) and that our code says we should run the SomeHandler method in response. The event handler is fired, as well as the other page events, and the updated page is sent back to the browser. That's the end of the postback cycle.