George Shepherd’s Microsoft ASP.NET 4 Step by Step is now available!
The book contains 26 chapters across 640 pages. This post will give you a taste of the book. The book’s chapter-level Table of Contents and Introduction can be found here.
Here’s the taste—enjoy:
ASP.NET and WPF Content
After completing this chapter, you will be able to
- Understand the benefits of Windows Presentation Foundation (WPF) over traditional Windows user interfaces.
- Create an XAML-based browser application (XBAP) site.
- Add WPF-based content to an ASP.NET site.
The last 20 chapters demonstrate how ASP.NET makes Web development approachable by pushing most HTML rendering to the ASP.NET Control class and its descendents. In addition, the ASP.NET pipeline hides many of the details of a Web request so that you can focus on your part in development. The next few chapters show alternative paths for producing content for the end user, including information on ASP.NET support for AJAX, its implementation of the Model-View-Controller pattern, and how Microsoft Silverlight works. This chapter starts by discussing how you can render Extensible Application Markup Language (XAML)-based content to the browser.
Improving Perceived Performance by Reducing Round-Trips
Throughout the history of the Web, one main way developers have improved end-user experience has been to reduce the number of round-trips to the server. For a long time, the only way to do this was to employ client-side scripting in a Web page. That way, certain parts of the application were executed on the client’s browser, which is usually much faster than making an entire round-trip.
Chapter 23, “AJAX,” discusses AJAX, which represents a major improvement in Web-based user interfaces (UIs). AJAX adds many elements to Web-based user interfaces that have been available previously only to desktop applications. For example, the AJAX AutoComplete extender allows users typing text into a TextBox to select from options generated dynamically from a Web service. With the ModalPopupExtender, you can provide content in a pane that behaves like a standard Windows modal dialog box at run time.
However, scripting isn’t the only way to push functionality to the browser. AJAX still relies fundamentally on HTML, and although HTML includes a huge set of tags that render to standard user interface elements that run in the browser, it stops there. Being able to run WPF content on a site changes that. WPF represents a new way to add rich user interfaces to a site, and it turns standard Web-based (and Windows-based) user interface programming
on its head. In this chapter, you see how WPF works and how it relates to the Internet and to browser applications. You revisit some of this when you look at Silverlight, a similar technology. For now, first look at WPF.
What Is WPF?
Windows-based user interface programming is based on an architecture that has remained fundamentally unchanged for more than a quarter century. Since back in the early 1980s through today, all applications have had the same basic underpinnings: The main application runs a message loop, picks up Windows messages off of the message queue, and deposits them into a window handler. Every window is responsible for rendering its own presentation—that is, every window, from the top-level window of the application to the most minor control in the window.
Nearly all Windows-based applications today use the Win32 application programming interface (API) at the lowest level. The classic Win32 API has worked well for a long time. However, its design is beginning to show its age. Because every window and control is responsible for its own rendering using the Win32 Graphics Device Interface (GDI, or the GDI+ interface, in the case of Windows Forms), fundamental user interface limitations are built into the design of the Windows operating system. The GDI and GDI+ interfaces have a huge array of functions. However, it takes a lot of work to do much more than basic drawing and text rendering. That is, special effects such as transformations, transparency, and video play integration are difficult to accomplish using the current Windows graphics interface. Windows does support a richer graphics-based interface named Direct X; however, using it is often beyond the scope of most Windows-based applications and is typically reserved for use by game programmers.
The limitations of the classic Windows API prompted Microsoft to develop a new programming interface: the Windows Presentation Foundation (WPF). With WPF, programming special effects for Windows-based applications (including presenting Web content, as described later) is very approachable. The WPF libraries are made up of a number of classes that work together very much like the Windows Forms classes do (on the surface at least; underneath the goings-on are very different from Windows Forms).
WPF represents a very rich programming interface for developing a user interface. Here’s a short list of the kinds of features available through WPF (this is a broad summary and is not exhaustive):
- User interface elements that you can modify in all kinds of ways much more easily than you can using Win32 and subclassing
- Paths, shapes, and geometries for drawing two-dimensional presentations
- Transforms (scaling, translating, rotation, and skewing) that allow consistent and uniform modifications to all user interface elements
- Ability to manage the opacity of individual elements
- Built-in layout panels
- Brushes—image, video, and drawing brushes for filling areas on the screen
WPF applications arrange the UI elements using layout panels. Rather than relying on absolute positioning (as is the case for Win32 applications) or flow layout (as is the case for ASP.NET pages), WPF introduces a number of layout options including the following:
Grid Elements are placed in a table.
StackPanel Elements are stacked vertically or horizontally.
Canvas Elements are positioned absolutely.
DockPanel Elements are positioned against the sides of the host.
WrapPanel Elements are repositioned to fit when the host is resized.
The example that follows later uses the Canvas.
You craft a typical WPF application from files in very much the same way that you create an ASP.NET application. A stand-alone WPF application includes a main application object that runs the message loop and one or more windows, which are browser-based WPF applications made up of pages. WPF application components are typically composed from a markup file, just like ASP.NET pages are. WPF layouts are defined using Extensible Application Markup Language (XAML).
XAML files describe a WPF layout’s logical tree, the collection of WPF user interface elements. A WPF application is made up of Common Language Runtime (CLR) classes underneath the façade of markup language, very much like the ASP.NET object model is. XAML files represent instructions for constructing a logical tree of visual elements. In the case of a stand-alone Windows application, the logical tree exists in a top-level window. In the case of a browser-based application, the logical tree exists in a browser pane. The following is a short XAML listing that displays “Hello World” in a button hosted in a browser pane:
<Button Height="100" Width="100">Hello World</Button>
The preceding code doesn’t do a whole lot, but it is an example of the fundamental structure of a WPF page as expressed in XAML. When run, the XAML you see listed starts a browser session and displays a button with the string “Hello World” as its content (provided the XAML plug-in is installed). In a real application, instead of containing a single button with a string, the top-level WPF node can contain elaborate layouts using the different layout panels available in WPF. You see an example of this soon.
How Does WPF Relate to the Web?
What does all this mean for Web applications? Windows Internet Explorer and other browsers running under the Windows operating system are based on the classic Windows architecture. Browsers are responsible for rendering HTML using the graphic interface available to Windows: the Graphics Device Interface (GDI). Consequently, accomplishing special effects in browsers (and typical HTML) is just as difficult as it is with traditional Windows programs.
Web programming is based on submitting HTTP requests to a server, processing the requests, and sending back responses to the client. In that sense, any user interface–specific responses are constrained to whatever can be expressed in HTML. The Web is dynamic, and HTML is basically a document technology.
Is there another markup language that provides more than just simple tags that can be interpreted by an HTML browser? Yes, that’s what XAML is when used in the context of a Web application.
Remember the previous code example? If the contents of the file are saved in an ASCII text file named HelloWorld.xaml, and you double click it in Windows Explorer, Internet Explorer loads and parses the XAML content. Figure 21-1 shows how it appears in Internet Explorer when you load the XAML file into the browser. Simply double-click the file name in Windows Explorer to see the application.
When adding WPF-style content directly to a Web site, you have three options: presenting the content through loose XAML files, creating an XAML-based browser application (XBAP), or using Silverlight. (Silverlight is described in more detail in Chapter 24, “Silverlight and
Loose XAML Files
As just shown, if you place a properly formatted XAML file in your site and make it available through a Web server, any browser capable of using the XAML plug-in (such as Internet Explorer) can pick it up and render it. This is one option for presenting WPF-based content from a Web site. This technique is useful for rendering semidynamic content—that is, for rendering anything expressible using pure XAML files.
The WPF programming model marries XAML layout instructions with accompanying code modules in very much the same way that ASP.NET does. Events generated from user interface elements are handled in the accompanying code. Deploying s as loose XAML files precludes adding event handlers and accompanying code.
However, WPF elements are dynamic in the sense that they can be animated, and user interface elements can be tied together using only XAML. That’s why WPF content expressed only through XAML is semidynamic. You can hook up some interactive elements using only XAML, but there’s a limit. For example, all through XAML you can render a list of names of images in a list box and allow users to select an image to zoom. You can attach slider controls to user interface elements so that the end user can change various aspects of the elements through the slider. However, you cannot implement event handlers for controls; that requires deploying a WPF application as an XBAP application.
XBAPs are another way to deploy WPF content over the Web. They’re a bit more complex than loose XAML files are. In addition to expressing layout, XBAPs support accompanying executable code for each page. When you deploy a WPF application over the Web, the client receives the WPF visual layout and the accompanying code is downloaded to the client computer. Events occurring in the XBAP are handled on the client side.
The upside of deploying an application as an XBAP is that it works in very much the same way that a Windows-based desktop application works (though with greatly reduced permissions and tightened security). For example, the application can handle mouse click events and can respond to control events all on the client side.
Although XBAPs are not related directly to ASP.NET, XBAP content can be hosted in ASP.NET-served pages in the same way that loose XAML content can be served. That is, you can make redirects to XBAP files or host XBAP files from within <iframe> HTML elements.
Creating an XBAP
1. Start Visual Studio and click File, New Project. Go to the Windows application templates and select WPF Browser Application. Name the Application XBAPORama, as shown here:
2. Visual Studio should have created for you a new XBAP that includes a page and an application XAML file set. The file names are Page1.xaml/Page1.xaml.cs and App.xaml/App.xaml.cs. This is very similar to the ASP.NET Web Form application structure in that there is a markup file that contains the bulk of the UI and a code file that implements functionality to be run on the client. Visual Studio should show the Page1.xaml file, which contains a Grid layout panel.
3. Change the layout panel from a Grid to a StackPanel so that it is simpler to work with. With a StackPanel, you can drop in controls and not worry about creating grid columns and rows:
4. Modify the XAML a bit more. Change the FontSize property for the Page to 16. Nest the following controls in the StackPanel: a TextBox, a ListBox, and a Button. WPF works very similarly to ASP.NET in that you can name controls in the markup file (the XAML file) and they will appear as programmatic elements in the code behind. Set the Name property for the TextBox to “theTextBox” and set the Name property of the ListBox to “theListBox” so that you can refer to them in the code files. Finally, set the Height property of the ListBox to 100 so that it will show up even if it is empty:
<ListBox Name="theListBox" Height="100"></ListBox>
<Button>Click to Add Items</Button>
The Designer should show all the controls in the StackPanel like this:
5. Double-click the button to add a handler. Visual Studio creates a handler for the button click. You can find the handler in the code file for the page. Because you didn’t name the Button, Visual Studio gave the handler a default name of Button_Click. The method looks very much like the ASP.NET button click handlers except the second argument is a RoutedEventArg instead of the .NET typical EventArg.
6. Implement the handler by adding whatever is in the TextBox to the ListBox. It should feel almost like you are programming a Web Form—the code model is very similar:
/// Interaction logic for Page1.xaml
public partial class Page1 : Page
private void Button_Click(object sender, RoutedEventArgs e)
7. Press Ctrl+F5 from within Visual Studio to run the application in the browser. When you type text into the TextBox and click the Button, the code running on the client side will add the contents of the TextBox to the ListBox, as follows (notice the .xbap extension at the end of the file name in the URL):
Although this example does not strictly run in ASP.NET, it does show an alternative way of producing content. When you compiled the application, Visual Studio created a few files including XBAPORama.xbap and XBAPORama.exe. You can include this content as part of an ASP.NET site by including the XBAP, the EXE, and the manifest files that resulted from the compilation in a folder in an ASP.NET application. You do that shortly.