Handling Events

Now let’s see how we can program against these server-side controls. If you were programming ASP pages in the past you know how cumbersome handling a single button click could be if there were several buttons on a page. You had to write code to figure out which button was clicked to invoke the appropriate function to handle the click. That is no longer the case with ASP.NET. Server-side controls already provide the plumbing to do the figuring out part and invoke the right method for you. With three simple and easy steps we can setup a handler method to handle a button click. First we add a member for the button to the class in the code-behind file, i.e. the base class of the page:

public class WebForm1 : System.Web.UI.Page

{

  // same as the id of the HTML tag

  protected System.Web.UI.WebControls.Button Button1;

}

Now we can access the button just like any other .NET object. It can check the button’s properties, or bind delegates to events exposed by the button to register event handler methods. To handle the click event we would bind a delegate to the Click event, but before we do this we need to add a method that we can bind to:

private void Button1_ClickHandler (object sender, System.EventArgs e)

{

  Response.Write( "You clicked Button1" );

}

The third step to set up the event handling is to bind the handler method to the event. We typically do this in a method called OnInit because the ASP.NET Framework is calling that method to set up the page:

override protected void OnInit(EventArgs e)

{

  this.Button1.Click +=

    new System.EventHandler(this.Button1_ClickHandler);

  base.OnInit(e);

}

With these few, simple lines of code, the ASP.NET page will know to call the Button1_ClickHandler method when a client clicks on the button. And as if that was not already easy enough, the web forms designer in ASP.NET performs all three steps for you when you click on the button in the designer window.

This concludes our brief introduction into handling events from web controls. We will see more about them later on in this chapter when we write pages to present XML data.

State Management

There is one more feature of ASP.NET I would like to introduce before we can finally move on to the XML related portion of this chapter. The event handling model we just learned about raises an interesting issue for those of us familiar with HTML and/or classic ASP pages. A click on a button in a web page submits the current state of all user interface elements, like textboxes, dropdown menus and radio buttons, to the server. The server then processes the data and sends back a brand-new HTML page for the browser to display. Many times the page coming back to the user is the same page on which the user clicked. It would be confusing if the elements on the returned page would not show the selections as before the user generated an event. However, ASP provided no support for initializing all the user interface elements on the new page from the submitted state of the old page. We had to write code to read data for each element on the page from the HTTP request and initialize the elements on the new page before we return it.

Fortunately we no longer have to write all this mindless, boiler-plate code to reinitialize elements on a web page. Since ASP.NET now heavily relies on posting data back to the server, Microsoft also added a nice feature to re-initialize the controls from the data submitted with the event. This feature is called ViewState. We can enable it for each web control by setting the EnableViewState property to true. We can set this property either from code or from the web form designer in Visual Studio.NET.

ViewState encapsulates a lot of powerful functionality, but once again we have to exercise caution to not over-use it. If ViewState is set to true then the data for every control will be posted back to the server. This can result in lot of data going across the wire when a the page contains
controls sophisticated controls like the DataGrid or the Tree View. Make sure you turn the ViewState off if you do not auto populate controls after you posted back data.

Figure 17.5: ViewState keeps page state to initialize web controls automatically.

Of course what we just discussed about ASP.NET and web control is just the tip of the iceberg. There is a lot of functionality that we cannot discuss in this section. After all you wanted to read about predominantly about XML processing and not about ASP.NET. I hope we had enough of an overview for you to understand the rest of this chapter even if you did not program ASP.NET pages before.