Web Forms are event-driven. An
event represents the idea that “something
happened.” An event is generated (or raised) when
the user clicks a button, or selects from a ListBox
, or otherwise interacts with the UI.
Events can also be generated by the system starting or finishing work.
For example, open a file for reading, and the system raises an event
when the file has been read into memory.
The method that responds to the event is called the event handler. Event handlers are written in C# and are associated with controls in the HTML page through control attributes.
By convention, ASP.NET event handlers return void
and take two parameters. The first
parameter represents the object raising the event. The second, called
the event argument, contains information specific
to the event, if any. For most events, the event argument is of type
EventArgs
, which has no members and
serves as a placeholder and as the base class for more specialized
objects that provide properties needed by the event handler.
In web applications, most events are handled on the server and, therefore, require a round trip. ASP.NET supports only a limited set of events, such as button clicks and text changes. These are events that the user might expect to cause a significant change, as opposed to Windows events (such as mouse-over) that might happen many times during a single user-driven task.
Postback events are those that cause the form to be sent (or posted) to the server and then to be returned to the browser (typically with updated data) The user’s experience is that the page is updated after a brief delay.
A button click, for example, causes the page to be sent to the browser, the event handlers are run, and then the same page is sent back to the browser.
To avoid this round trip to the server happening too frequently, many events such as changing the text in a textbox or clicking a checkbox are non-postback events. When these events fire, the form is not posted back, but the event is saved by the control, and handled the next time the page is posted back.
The web does not maintain state. By design, it is a stateless environment. That means that the server would normally have no idea that a second post from a given user has any association with previous posts by that same user. That is fine if all you have are one or two pages that are information only, with no interaction, but it is obviously limiting if you want to create an interactive application.
ASP.NET solves this problem by maintaining three types of state: view state, session state, and application state:
Maintains the value of controls (what you’ve filled into text boxes, which choices you’ve made in lists) when you post a page to the server. There was a time you had to write code to do this, but it is now done for you in an efficient and reliable manner.
Creates an artificial “connection” with the application, simulating the idea of an ongoing session for an individual user within a single application. This is so natural, you hardly notice it. You go to a site, and as you interact with it, remembers your input and responds accordingly, just like working with a desktop application. Sessions typically end by “timing out” after about 20 minutes of inactivity; but in most cases, this is invisible to the user.
Preserves values across users within a given web application. Application state is beyond the scope of this chapter.