I l @ ve RuBoard |
The creation of Web-based interfaces and their associated functionality accounts for a major part of most application development. One reason that HTML became so popular was its simplicity ” anyone with a text editor could create their own Web pages. HTML works fine for static Web content, but in an application that will use Web pages for its user interface, the Web pages must interact with the application functionality and their content must change to display application data to the user . Such Web pages must contain some executable content to interact with the main application code, in addition to fixed HTML. Few people can create such Web pages using just a text editor ”and even fewer would choose to do so. A Web-based application runs in a specific context:
This description is intentionally generic ”the Web means different things to different people. However, for most people the Web is synonymous with browser-based applications and content. Browser-Based Web ApplicationsThis chapter focuses on developing systems in which the client is assumed to be a Web browser. (The next two chapters will cover Web services, in which client applications can be almost any type of executable program.) The context in which a browser-based application operates has the following characteristics:
Although these two characteristics are required, many variables remain . The browser might be Microsoft Internet Explorer, Netscape Navigator, or Opera, for example. Even if your application is targeted at an intranet environment in which only Internet Explorer is used, you must still address the issue of handling the different levels of functionality available in different versions. As a Web application developer, you must typically make a decision about reach versus richness. In other words, should you develop a very functional application that can run only in Internet Explorer 5.5 and later, or should you create an application with a simpler interface and less functionality that can run on almost any browser? It's difficult to create an application that can adapt to the type of client and provide an appropriate level of richness. However, as you'll see, ASP.NET Web controls can help an application adapt to different clients and still deliver a rich user interface. The ASP.NET EnvironmentAn ASP.NET application, like its ASP predecessor, runs using Microsoft Internet Information Services (IIS). The files that make up an ASP.NET application reside in a virtual directory configured under IIS. An example of such a virtual directory is http://www.fourthcoffee.com/FourthCoffee . Typically, this directory is mapped to a folder under the Inetpub\ wwwroot folder. Requests for files that reside below the virtual directory are handled by IIS. IIS can implement some of the security required by the application (as discussed later) and can deliver requested HTML and media files to the client. IIS also maintains a list of filename extensions that are associated with particular server-side functionality. You can view these settings by starting the Internet Information Services management snap-in. In Control Panel, select Performance and Maintenance. In the pane that appears, select Administrative Tools and double-click on Internet Information Services. Open the entry for your computer (or the server on which you'll deploy your Web applications) and open the Web Sites folder. Right-click Default Web Site and choose Properties from the shortcut menu to display the Default Web Site Properties dialog box. Click on the Home Directory tab, and under Application Settings click the Configuration button. The resulting Application Configuration dialog box is shown in Figure 16-1. Here you specify how files with different extensions are mapped to associated server-side functionality. The main functionality of ASP.NET Web applications is contained in ASP.NET pages, which have an .aspx filename extension. If you examine the line in the Application Mappings table for ASPX files, you'll see that these files are mapped to \Windows\Microsoft.NET\Framework\.NETVersion\aspnet_isapi.dll. This means that when a client requests an ASPX file, the request is delegated to the ASP.NET runtime (found in aspnet_isapi.dll), which executes the server-side functionality contained in such files. Figure 16-1. The IIS Application Configuration dialog box, which shows the mapping of file types to server-side functionality
So far, so good. However, this is not really any different from the way an ASP application works. ASP.NET gets its additional power from hosting the .NET common language runtime. Consequently, any ASP.NET page has access to the features and functionality of the .NET Framework. For example
Fortunately, such benefits come without ASP developers having to sacrifice the model they're familiar with. The Basic ASP.NET Programming ModelThe basic ASP.NET programming model is essentially the same as that of ASP. The URL of the client request identifies a particular ASP.NET page, the functionality on the page is run, and any output generated is delivered back to the client. The format of an ASP.NET page will look familiar to an ASP developer. Consider the code shown in Welcome.aspx, which is provided as a sample file in the FourthCoffee solution. Welcome.aspx<%@Pagelanguage="VJ#" %> <HTML> <% System.StringourName= "FourthCoffee"; System.StringoptimalBrowser= "IE"; System.StringthisBrowserName=get_Request().get_Browser().get_Browser(); %> <body> <Palign="center"><FONTsize="5"><STRONG>Welcometo<%=ourName%> </STRONG></FONT></P> <% if(thisBrowserName.Equals(optimalBrowser)) { %> <P><%get_Response().Write(ourName);%>arehappytowelcomeusers ofInternetExplorer.</P> <% } else { %> <P>ByemployingASP.NETWebcontrols, <%get_Response().Write(ourName);%>canalsoeasilywelcome usersof<%=thisBrowserName%>browsers.</P> <% } %> </body> </HTML> As you can see, you can embed code within the HTML contained in an ASP.NET page by using code render blocks that start with <% and end with %> . These blocks will be familiar to ASP developers, as will the ability to evaluate expressions using the syntax <%= expression %> . The code in Welcome.aspx uses code render blocks to wrap J# code around HTML statements. The if statement checks to see what browser the user is running and displays a message based on that browser, as shown in Figure 16-2. Figure 16-2. You can embed J# code in an ASPX page to perform many tasks , including determining which browser a user is running.
The page shows several features of ASP.NET:
Just to prove that there's nothing up our sleeves, you can see the result of running the page in another browser in Figure 16-3. Figure 16-3. The server-side J# code can generate different output for different types of client Web browser.
One difference between ASP.NET and ASP is that in ASP.NET you can no longer define functions or subroutines in code render blocks. Instead, you must use method declarations enclosed in script tags: <scriptrunat="server"> System.Web.HttpBrowserCapabilitiesthisBrowser; System.StringthisBrowserName; privatevoidSetBrowserInfo(System.Web.HttpRequestreq) { thisBrowser=req.get_Browser(); thisBrowserName=thisBrowser.get_Browser(); } </script> It's important to remember the runat="server" attribute ” otherwise , the code will be interpreted as client-side script and you'll get errors when the page is processed . Also note that the script tag is not a direct replacement for code render blocks. You cannot use it to delimit inline code ”you can use it only to declare functions and variables. An example of the use of the <script> tag is provided in the Welcome2.aspx sample file. By default, the language for code in a script element is assumed to be that defined in the <%@ Page %> directive. If you haven't defined a page-wide language, the application default will be used. Each Web application will have a default language defined in the compilation element of its Web.config file: <configuration> <system.web> <compilation defaultLanguage="VJ#" debug="true" /> </system.web> </configuration> This default definition is overridden by a page-level language declaration. All code in code render blocks must be written in the language defined either by the language attribute of the <%@ Page %> directive or the Web.config compilation element. We'll look at the syntax and content of the Web.config file in more detail later. The sample file Welcome3.aspx uses the <%@Page %> directive to override the default language defined in Web.config (J#) and use Visual Basic .NET instead. If you haven't set the language for the page, you can override the application-level default language using the language attribute of the script element: <scriptrunat="server" language="C#"> </script> Be careful with this feature: You can use only one language per page, so if you declare the language in multiple places, the declarations must match. If you try running the sample file Welcome4.aspx, which contains a mixture of J# and Visual Basic .NET code, you'll get a compilation error. You might wonder why the default language is defined in an element called compilation . There's a good reason for this. As mentioned earlier, when an ASPX page is first accessed, the text and code are converted into a new class that will contain any code defined in the ASPX page along with code commands to output the static HTML content at the appropriate place. This new class is then compiled into MSIL and executed. The precise mechanism is described later in the chapter. To do any real work in your Web application, you must access the .NET Framework or classes that you've written yourself or obtained from third parties. To use a class in your page, you can specify its fully qualified name: <%System.Xml.XmlDocumentdoc=newSystem.Xml.XmlDocument();%> However, this can soon become tiresome, so you can import the whole namespace (as you can in J#) by using the <%@ Import %> directive: <%@Importnamespace="System.Xml" %> <%XmlDocumentdoc=newXmlDocument();%> You can see this example of importing a namespace in the sample file Welcome2.aspx. By default, the following namespaces are imported into an ASP.NET page:
You must ensure that the assemblies containing the classes you're importing are available to the page both at compile time and run time. If you place the assemblies in the bin directory under the Web application's virtual directory, they'll be automatically linked to the application. You must link any other assemblies explicitly by using the <%@ Assembly %> directive to link the assembly to the current page. |
I l @ ve RuBoard |