Locking the Screen During a Postback

In a perfect world all web applications would be snappy and responsive, and there would be no such thing as lengthy postback waits. But in the real world there are plenty of scenarios that take seconds to complete. For example, when a user visits a travel booking site like Expedia and enters his origination and destination information, it's not unusual for it to take several seconds before the search results appear. Similarly, I've worked on applications where clicking a button dynamically generated and e-mailed a large PDF file, or that have needed to query a very slow database located in corporate offices halfway around the world. In such cases it was not uncommon for the user to have to wait several seconds between submitting the form and getting a response from the web server.

While browsers provide some feedback to the user that the form has been submitted and a response is forthcoming, these visual cues are usually in the margins of the browser and still allow the user to interact with the page, re-click the button, or interact with some other user interface element on the page. Most travel sites send the user to a "Please Wait While We Process Your Results..."-type page when they submit their query. This does two things: it provides the user with visual feedback that their submission was accepted, and it prohibits them from re-submitting their search query twice.

You can mimic "Please Wait While We Process Your Results..." functionality in a single page with a bit of JavaScript and CSS that locks the screen upon a particular client-side action (typically a form submission), displaying a message and prohibiting the user from interacting with the web page. This article shows how to inject such functionality into an ASP.NET web page. Read on to learn more!
Read More >

Key Configuration Settings When Deploying a Web Application

The configuration information for an ASP.NET application is stored in one or more XML-based configuration files named Web.config. The default configuration settings for all web applications on the web server are spelled out in the Web.config file in the $WINDOWS$\Microsoft.NET\Framework\version\CONFIG folder. These default settings can be added to over overridden for a specific web application by the Web.config file in that application's root directory. Moreover, these configuration settings can be customized for a web application on a folder-by-folder basis by adding Web.config files to the application's subfolders.

The Web.config file spells out an array of configuration settings, including: database connection strings, authentication and URL authorization rules, and the behavior that unfolds when an unhandled exception occurs, among many others. Many configuration settings differ between the development environment and the production environment. For example, when you are developing an ASP.NET application on your desktop you are likely using a different database than when the application is in production. Consequently, the database connection strings in Web.config need to be updated when deploying an application.

Some of these types of configuration settings must be changed when deploying an application, like database connection strings. Failure to modify the configuration information when deploying will cause the web application not to work in production. These types of configuration settings are easy to remember to change. But there are a number of configuration settings that should be changed when deploying an application, but if they are not changed the application will still work in production. These configuration settings are easy to forget to change, and forgetting to change them can reduce the performance of your application or make it more vulnerable to attacks from malicious users. This article details a handful of configuration settings that fit into this latter category. Read on to learn more!
Read More >

Modifying the HTTP Response Using Filters

When a browser requests an ASP.NET page from a web server, the ASP.NET engine takes that request through a number of steps that, together, generate the resulting markup, which is returned to the requesting browser for display. The stages in this process are referred to as the HTTP Pipeline and perform tasks like authentication, authorization, and having the requested page render its content. During one of the later stages in the HTTP Pipeline the rendered markup is handed off to a response filter which, if supplied, has an opportunity to inspect and modify the markup before it is returned to the requesting browser.

With a little bit of code you can create your own response filters and associate them with a particular page, a particular type of page (such as ASP.NET resources that generate HTML), or for all ASP.NET resources. And if you are using IIS 7's integrated mode you can have your filter work with the output of any content type. This article provides an overview of response filters and shows two such filters: a naive filter that strips out whitespace to reduce the size of the markup sent over the wire, and a filter that adds a copyright message to the bottom of all web pages. You can download these two filters, along with a simple demo application, at the end of this article, with examples in both C# and Visual Basic.

Read on to learn more!
Read More >

A Google Chart API Custom Server Control

Last week's article, Creating Charts with the Google Chart API, looked at how to use Google's free Chart API to generate line, pie, bar, and other types of charts from an ASP.NET page. The Google Chart API is callable via a URL that contains the chart type, size, data, and other parameters in the querystring and returns the chart as an image. Displaying a chart using this API is as simple as adding an Image Web control to a page and setting its ImageUrl property to the Google Chart API URL with an appropriately formatted querystring.

Last week's article explored the essential querystring parameters and provided an example on how to programmatically construct this querystring to plot data from a database query. In a nutshell, constructing this querystring involved about 50 lines of code to get the data, express the data as percentages relative to one another, and build up the other parameters. Wouldn't it be much easier if we could create a chart by dropping a Google Chart API Web control on the page, set a few properties, and then bind it to a data source control, like a SqlDataSource or ObjectDataSource? That way we could create and display charts using the Google Chart API without having to write a lick of code.

Over the past week I built such a Web control. The Web control does not provide the full suite of Google Chart API features - it only allows for the creation of line, bar, and pie charts, and it only allows a single data series - but it makes creating and displaying data-driven charts as easy as drag-and-drop and point-and-click. This article shows how to use this free custom server control and highlights some of its more interesting aspects. You can download the compiled server control, its complete source code, and a demo application at the end of this article. Read on to learn more!
Read More >

Creating Charts with the Google Chart API

I've always wondered how the phrase "A picture is worth a thousand words" came about. I like to think that it was coined by some mid-level manager viewing a sales figures report that consisted of metrics from the past 1,000 days. After scanning this long list of numbers, he found, at the bottom of the page, a line chart that summarized the numbers, and uttered that now well-known adage. Charts and graphs provide a succinct synopsis of large amounts of data. With charts a person can quickly spot trends, compare different resultsets, or recognize patterns.

There are many ways to create charts in an ASP.NET web page. You can use the classes in the System.Drawing namespace to programmatically generate charts; you can use the Microsoft Office Web Components (OWC). There are also open-sourcecharting tools and a plethora of third-party components, as well. Microsoft has even entered the game and introduced Microsoft Chart Controls for the .NET Framework 3.5 SP1.

This article looks at how to use the to create charts. The Google Chart API is a free service from Google that enables web developers to generate chart images on the fly by creating an element with a src attribute that points to a URL that includes the chart data, labels, and other information in the querystring. For instance, the chart on the right is available at the URL http://chart.apis.google.com/chart?cht=p&chs=225x150&chd=t:100,30,70,25&chl=Q1|Q2|Q3|Q4&chtt=2008%20Sales%20By%20Quarter. Read on to learn how to use the Google Chart API in your ASP.NET website!
Read More >

Troubleshooting Website Problems by Examining the HTTP Traffic

I started my career as a web developer with Microsoft's Active Server Pages (ASP), the predecessor to ASP.NET. ASP was a very simple scripting engine and lacked the tools that ASP.NET developers today take for granted, most notably a debugger. Debugging an ASP script typically involved littering the code with Response.Write statements to output the values of variables at different points in time of the script's life-cycle. Debugging an ASP.NET page is so much easier thanks to the Visual Studio debugger, which allows you to set breakpoints, step through executing code, use Watch windows to keep an eye on variable values as they change, and an Intermediate window to evaluate statements during debug time.

While the Visual Studio debugger has greatly improved the debugging story, there are certain scenarios where a server-side debugger is of little or no help. In certain cases the problem is not in the server-side code but instead in what is being sent from the client to the server (or vice-a-versa). These types of scenarios are quite common when creating AJAX-enabled web applications, as the data exchanged between the client and server during a partial page postback affects the code executed on the server-side and how the page is updated on response. This technique is also quite useful when debugging pages that perform different Response.Redirects based on various parameters, or when trying to ascertain why images, videos, or other external content is not properly loading on a web page.

Unlike debugging server-side code, examining the HTTP traffic sent between the client and the server is typically done on the client - namely, from the browser rather than from within Visual Studio. Fiddler is a free, excellent tool for debugging HTTP traffic. This article provides an overview of Fiddler and shows how to use Fiddler to assist with debugging. Read on to learn more!
Read More >

Converting Flat, Comma-Delimited Values Into a Normalized Data Model

In my job as an independent software developer I help a lot of small businesses enhance their existing company website or internal web applications to include new features or adopt best practices. Many of these businesses have vital line of business applications that were created many years ago by an employee who was not a professional software developer, but perhaps a member of the IT team or someone who was learning how to program or programmed as a hobby. A common mistake made by people without a solid background in creating data-driven applications is using flat, non-normalized data models.

Consider an application used in a healthcare setting may need to record each doctor's professional and educational degrees. Because there are a fixed number of degrees - PhD, MD, DDS, OB/GYN, RN, etc. - these degrees should be spelled out in a separate database table. And because each doctor can have multiple degrees, there should be a third table that maps what doctors are associated with what degrees. Such a data model would be normalized. A non-normalized data model would instead try to capture each doctor's degrees within the same table that contains the doctor's other information (his name, address, DOB, etc.). This might be implemented as several columns in the table (Degree1, Degree2, Degree3, and so on) or as a single column that contains a comma-delimited list of degrees, like "PhD, MD, OB/GYN".

While there are certain circumstances where non-normalized data is ideal, in the vast majority of situations having the data expressed in a normalized manner is ideal. Normalized data is easier to work with, is easier to report against, is (usually) more efficient in terms of both disk space and time to execute queries, and is less likely to suffer from any data integrity issues, which are all too common in non-normalized data. I recently helped a client who had a many-to-many relationship implemented in a flat, non-normalized manner convert that data into a normalized data model through the use of a T-SQL script. This article discusses why it is worhtwhile to convert flat, non-normalized data into a normalized data model and steps through how this T-SQL script can be used to normalize your data. Read on to learn more!
Read More >