Understanding Server-Side Events

Server-side events are one of the fundamental changes in the ASP.NET architecture, compared to older versions of ASP. These server-side events provide for a programming model that is very similar to that of a traditional event-model Visual Basic application. The code for these events is generally stored in a separate file called a code-behind file. This allows for separation between your client and server code, making things much more organized and structured. The code-behind file simply contains everything that used to be contained within the <%%> files in your old ASP pages; however, it is strictly code without any HTML.

Now let’s see what events are available to you on the server and how you can exploit them to your advantage.

Differences from Client-Side Events

The major difference between client-side events and server-side events, obviously, is that server-side events are handled on the server. This adds a great degree of flexibility and power to the existing ASP framework. It also provides for far more structured code.

Client-side events are part of the DHTML standard. They can be scripted in either JavaScript or VBScript, and they are embedded directly in the HTML of your page. These events allow you to trap button clicks, tab out of text boxes, detect the presence of the mouse cursor over certain controls, and handle other events that involve a user changing something on the client-side interface.

Server-side events enable you to respond to similar events, such as changing a text box or clicking a button, but, obviously, these are handled on the server instead of the client. Because a trip to the server is required to activate these events, only a small subset of events is available. These are generally limited to “click-type” events rather than “mouse-over” events. Imagine having to make a trip to the server every time your mouse moved 1 pixel!

Types of Server-Side Events

The types of events available on the server are very basic. For example, you will be able to respond to button clicks, text box changes, and drop-down box changes.

Take a look here at what one of these events looks like on the server. Listing 1.1 shows a very simple ASP page that contains a form with a text box and a Submit button.

Listing 1.1. Simple ASP Page with a Form
<HTML> 
<BODY> 
    <FORM ACTION="form.aspx" METHOD="POST" RUNAT="server"> 
        <INPUT TYPE="text" ID="txtText" RUNAT="server"> 
        <INPUT TYPE="submit" ID="btnSubmit" RUNAT="server"> 
    </FORM> 
</BODY> 
</HTML>

You will notice that this looks like some plain old HTML. However, you should note the addition of the RUNAT="server" parameter added to each control. This enables you to trap the events on the server and respond to them appropriately.

Now take a look at a server-side event associated with both the text box and the Submit button. Listing 1.2 shows this in C#.

Listing 1.2. Server-Side Events in C#
public void btnSubmit_ServerClick(sender As Object, e as EventArgs) 
{
    txtText.Value = "You clicked the Submit button!"; 
} 

protected void txtText_TextChanged(object sender, EventArgs e) 
{
    Response.Write("TextChanged: " + txtText.Value); 
}

Listing 1.3 shows the same event examples in Visual Basic.

Listing 1.3. Server-Side Events in Visual Basic .NET
Private Sub btnSubmit_ServerClick (sender As Object, e as EventArgs) 
    txtText.Value = "You clicked the Submit button!" 
End Sub 

Sub txtText_TextChanged(sender Object, e As EventArgs) 
    Response.Write("TextChanged: " & txtText.Value) 
End Sub

In each of these examples, two separate events are being handled on the server: a Submit button being clicked and the value of a text box being changed. Each event that is handled on the server takes the Object and EventArgs arguments. The object is simply the object that sent you the event (for example, the button, the text box, and so on). The EventArgs argument contains any event- or object-specific arguments that are relevant to the object being acted upon.

ASP.NET Page Life Cycle

The life cycle of an ASP.NET page is similar to that of an ASP page. However, you can hook into a few new events as well. Table 1.1 runs down the events of an ASP.NET page.

Table 1.1. Events in the Life Cycle of an ASP.NET Page
EventDescription
Page_InitThis is the first event to be called in the process. Here you should provide any initialization code required for instantiation of the page.
Page_LoadAt this point, control view state is restored. You can now read and update control properties.
Page_PreRenderThis event is raised before any page content is sent to the browser.
Page_UnloadThis is the very last event to be raised.At this point, you should clean up everything you have used, including closing connections and dereferencing objects.

In terms of the life cycle of your ASP.NET application, quite a few new events can be used inside the global.asax file. The events that can be hooked into in global.asax are described in Table 1.2.

Table 1.2. Events That Can Be Used Inside global.asax
EventDescription
Application_StartRaised only once, when the application starts for the first time. Initialize application-wide things here.
Session_StartRaised when a new user’s session begins.
Application_EndRaised when your application shuts down or is reset. Clean up here.
Session_EndRaised when a user’s session times out or is reset.
Application_ErrorRaised when an unhandled exception is raised (those not caught in a try/catch block). You could call a logging routine here.
Application_BeginRequestRaised every time a new request is received at the server.
Application_AuthenticateRaised when the request is to be authenticated.You can provide custom authentication code here.
Application_AuthorizeRequestRaised when the request is to be authorized. Again, you can provide custom authorization code.
Application_ResolveRequestCacheRaised to enable you to stop the processing of requests that are cached.
Application_AcquireRequestStateRaised to enable you to maintain state in your application (session/user state).
Application_PreRequestHandlerExecuteThe last event to be raised before the request is processed by the ASP.NET page or a web service.
Application_PostRequestHandlerExecuteRaised after the handler has finished processing the request.
Application_ReleaseRequestStateRaised to enable you to store the state of your application.
Application_UpdateRequestCacheRaised when processing is complete and the page is going into the ASP.NET cache.
Application_EndRequestRaised at the very end of your request.
Application_PreRequestHeadersSentRaised before HTTP headers are sent to the client. Here you can add custom headers to the list.

Now you can’t say that you don’t have enough control of what happens when and where in your ASP.NET application. These events also provide excellent places to hook into the ASP.NET processing chain for debugging, as you will see in some later chapters.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset