Beginning Web Development, Silverlight, and ASP.NET AJAX

CHAPTER 3 ■ WEB FORMS WITH ASP.NET 53
workflow that HTML forms offer, something is necessary to bubble the events up to the
server so that the server knows what event to respond to. The flow of processing follows
this model:
• When the page first runs, ASP.NET parses through the declarations and generates
HTML to be sent to the client. All objects that it uses are destroyed from server
memory once the HTML has been generated and issued to the client.
• The user triggers a postback to the server, either by clicking an HTML submit button
or performing an action that the server will interpret as an event, such as
checking a CheckBox control.
• When the page is returned to the server, ASP.NET is able to interpret the view state
information to restore the state of each of the controls.
• The view state information also contains the operation that triggered the postback.
ASP.NET obtains this information and raises the appropriate event, and if you’ve
written an event handler for this event, then your event handler’s code will execute.
Other events that didn’t cause the postback will also fire, such as a list selection,
and if you’ve provided an event handler for those events, you can process them
as well.
• The modified page is rendered back into HTML and returned to the client, and all
objects—including those invoked by the event handlers—are destroyed.
Not all client browser events fire a postback right away, and ASP.NET is designed to
process each event at the most appropriate time. For example, if you come from a Windows
development background, you may know that the Windows Forms TextBox fires a
TextChanged event whenever the user types something into the text box. However, in a
web context, you wouldn’t want to do this, because you’d trigger a postback every time
you press a key when the cursor is in a text box, severely hampering your application’s
performance and scalability. Instead, the web-based text box triggers a postback when
you press Enter or Tab if so configured.
However, when you start getting into complex controls, you may not want to use a
postback for every user interaction. Consider a scenario where you have a UI containing
a list control. In some cases, you might want to have a postback when the user selects an
item on the list (so that you can respond to it right away), and in other cases, you might
not want one. You can set up the former situation using an automatic postback (using the
control’s AutoPostback property), where the control triggers the postback instead of the
user. For the latter, just query the status of the list when the user selects a submit button
or something similar to generate a postback for the page.
Listing 3-10 shows a simple web UI containing a three-item list. This list has an event
handler defined for it that is designated to fire whenever the list selection changes.