Programming an ASP.NET Application: Changes from ASP.old

This chapter is from the book

Visual Basic .NET Developer's Guide to ASP .NET, XML and ADO.NET

Learn More Buy

This chapter is from the book

This chapter is from the book 

Visual Basic .NET Developer's Guide to ASP .NET, XML and ADO.NET

Learn More Buy

Creating User Interfaces with Web Controls

The .NET framework provides a number of user-interface components you can use.

These components are divided into several categories:

• HTML controls—An object-oriented way of creating standard HTML page elements such as text boxes and buttons

• Web forms controls—Objects that can incorporate standard and dynamic HTML into rich user-interface elements

• Validation controls—A type of Web form control specifically geared toward validating user input on a form, often without causing a round trip to the server. Validation controls are covered in Chapter 12, "Creating Database Applications with ADO.NET."

This section will show you how to use the controls that are included with the .NET framework. You can also create your own Web forms controls; this is covered in Chapter 10.

Programming Web Forms Controls

The first step to using Web forms controls on a page is to create an ASP.NET Web form. You do this by creating a conventional HTML FORM tag with the ASP.NET runat="server" attribute, as shown in Listing 3.26.

Listing 3.26 Basic ASP.NET Web Form Declaration

<form id='myform' method='post' runat='server'>

</form>

Control Event Model

Web controls raise events of their own as well as the events of the classes they inherit.

Web controls that inherit from System.Web.UI.WebControl.WebControl raise the events listed in Table 3.3.

Table 3.3 Events Raised by Web Controls

Taking Advantage of Postback and View State

Postback is the ASP.NET feature that enables you to detect whether a form has been submitted to the server. View State is a related concept that causes the contents of a posted-back form to be preserved.

The concepts of postback and View State grew out of a frustration with traditional Web server scripting paradigms. In a Web form, as with most HTTP Web requests, the page is completely destroyed and re-created each time it is submitted to the server. But in many, if not most cases, you want certain values (such as the contents of a Search box or the selection you've made in a list of custom preferences) to remain on the page. Without View State, you'd have to write code to make this happen, and without postback detection, it's tricky to determine whether the existing form data needs to be displayed.

You can determine whether an ASP.NET Web form is being posted back to the server by inspecting the IsPostBack property of the Page object. The first time a user accesses the page, IsPostBack will be false. At this time, you typically perform initialization work in code. This can be as straightforward as setting defaults in controls or as involved as performing a relational database query to serve as the basis for display on the page.

Earlier in this chapter, Listing 3.5 demonstrated the HTML source of an ASP.NET Web page that contains chunks of encoded View State. Listing 3.27 shows a snippet of that voluminous code listing.

Listing 3.27 HTML Source for an ASP.NET Page Highlighting View State Information

  <form name="WebForm1" method="post" action="calendar.aspx" id="WebForm1">
<input type="hidden" name="__VIEWSTATE" value="dDw1MzYzNjkxODU7Oz4=" />

    <table id="Calendar1" cellspacing="0" cellpadding="2" border="0" 
    style="border-width:1px;border-style:solid;border-collapse:collapse;">
     <tr>
      <td colspan="7" style="background-color:Silver;">
        <table cellspacing="0" border="0" 
         style="width:100%;border-collapse:collapse;">
         <tr>
          <td style="width:15%;">
           <a href="javascript:__doPostBack('Calendar1','prevMonth')"
            style="color:Black">&lt;</a>

Note that we've mercifully deleted the majority of the source code for brevity. You won't have to write this code yourself; fortunately, ASP.NET generates it for you from the high-level ASP.NET controls you specify.

You can see that the View State information is embedded in the page as a hidden control with the name __VIEWSTATE. The value is encoded, but not encrypted.

You should also be able to see that a hyperlink (a tag) toward the end of the code snippet is attached to an automatically generated JavaScript procedure called __doPostBack. This procedure parses the contents of View State and submits the form back to the server.

The ultimately cool thing about View State is that you don't have to lift a finger to make it work. You may choose to turn it off, however; getting rid of View State when you don't need it can provide a bit of a performance gain. To turn View State off for a particular control, set the control's ViewState property to false. (View State can also be shut off for a particular page or an entire Web application by using @Page directives, described earlier in this chapter, and Web.config settings, described in Chapter 6.)

Mobile Controls

The Microsoft.NET framework supports devices with small form factors and limited capabilities, such as mobile phones and Pocket PCs. These devices have demands on the user-interface developer that are totally different from the challenges presented by user-interface design on a desktop PC.

An in-depth discussion of mobile Web forms is beyond the scope of this book; however, many of the techniques discussed in this chapter will give you a good foundation for creating applications for mobile devices. Because the technical implementation (involving HTML, Dynamic HTML, WAP, and so forth) is abstracted behind the .NET Base Class Library, you can use similar programming techniques to code for Windows and Windows CE.

Data Binding

It is possible to bind a data source to controls in ASP.NET. This works both for rich Web forms controls and HTML controls.

For more information on data binding, see Chapter 12.

Determining Browser Capabilities

When you're creating a corporate intranet, you can often specify corporate standards for a Web browser. Although this tends to limit user choice, this is useful for the developer because it means you can utilize the capabilities of a specific Web browser. For Web sites that are intended to be used by the general public, though, you can't know ahead of time what kind of browser the users will have. In this case, you may find it useful to have a programmatic way of determining things about the user's browser. For example, does the user's browser support JavaScript (or, perhaps, did the user deactivate JavaScript support)? How about cookies? Even though most modern browsers support them, users can choose to turn those off, too.

The HttpBrowserCapabilities class, found in the System.Web namespace, provides these capabilities in ASP.NET. An instance of an HttpBrowserCapabilities object is contained by the ASP.NET Request object (in this context an instance of the object, called Browser, is created for you automatically when a page is requested from the server). Listing 3.28 shows how to use this pre-created object to display information about the browser.

Listing 3.28 Complete Listing of All HttpBrowserCapabilities Contained in the Request Object

<%@ PAGE language='VB' debug='true' trace='false' %>

<HTML>
<HEAD>
<TITLE>ASP.NET Browser Capabilities</TITLE>
</HEAD>

<BODY>
<table width="350" border="0" cellspacing="1" cellpadding="3" 
  bgcolor="#000000">
 <tr bgcolor="#FFFFFF"> 
  <td>Supports ActiveX Controls</td>
  <td><% =Request.Browser.ActiveXControls %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Is an America Online Browser</td>
  <td><% =Request.Browser.AOL %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Supports background sounds</td>
  <td><% =Request.Browser.BackgroundSounds %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Is a beta version browser</td>
  <td><% =Request.Browser.Beta %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Browser name (user-agent)</td>
  <td><% =Request.Browser.Browser %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Supports Channel Definition Format</td>
  <td><% =Request.Browser.CDF %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Common Language Runtime version</td>
  <td><% =Request.Browser.ClrVersion %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Cookies available</td>
  <td><% =Request.Browser.Cookies %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Is this a Web search engine (&quot;crawler&quot;)?</td>
  <td><% =Request.Browser.Crawler %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Version of JavaScript (ECMAScript) supported</td>
  <td><% =Request.Browser.EcmaScriptVersion %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Supports frames</td>
  <td><% =Request.Browser.Frames %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Supports client-side Java</td>
  <td><% =Request.Browser.JavaApplets %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Supports JavaScript (ECMAScript)</td>
  <td><% =Request.Browser.JavaScript %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Browser version</td>
  <td>
   <% =Request.Browser.MajorVersion & "." & _
Request.Browser.MinorVersion %>
  </td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Microsoft XML Document Object Model version</td>
  <td><% =Request.Browser.MsDomVersion %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Operating system platform</td>
  <td><% =Request.Browser.Platform %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Supports HTML tables</td>
  <td><% =Request.Browser.Tables %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Client browser type</td>
  <td><% =Request.Browser.Type %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Browser supports VBScript</td>
  <td><% =Request.Browser.VBScript %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Version of client browser</td>
  <td><% =Request.Browser.Version %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>W3C HTML Document Object Model version</td>
  <td><% =Request.Browser.W3CDomVersion %></td>
 </tr>
 <tr bgcolor="#FFFFFF"> 
  <td>Running 16-bit Windows?</td>
  <td><% =Request.Browser.Win16 %></td>
 </tr>
 <tr bgcolor="#FFFFFF">
  <td>Running 32-bit Windows?</td>
  <td><% =Request.Browser.Win32 %></td>
 </tr>
</table>
</BODY>
</HTML>

I used godless, archaic render blocks to create this page, mainly to make it easier for me to create, but also to make it simpler to read.

If you have more than one kind of browser installed on your computer, you may find it interesting to navigate to this page using both of them to see the different capabilities reported by the Browser object. For example, I found it interesting to learn that JavaScript 1.2 comes with Internet Explorer 6.0 beta, but that Opera 5.0 comes with the (presumably bigger and badder) JavaScript 1.3. Also, Opera doesn't return operating system platform information to the server the way Internet Explorer does. It's just as well; with well-designed Web applications, the server shouldn't need to know what operating system the browser is running on anyway.