Avoiding Annoying Mistakes in Your ASP.NET Web Applications

CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Thinking about technology alone, developing a feature-rich, performing, and secure ASP.NET web application is a challenge. However, a great web application is not just about backend code; instead, it is a combination of skillful design and coding.

In this article, you will learn to tackle subtle, yet common, web application mistakes, and thus create cleaner, easier to use ASP.NET web applications. Although some of the mistakes are not specifically tied only to to ASP.NET applications, the solutions given will use C# code.

However, you should keep in mind that this kind of article is not a complete list of all possible design and development oversights that can exist in ASP.NET applications. Instead, the focus is on issues that users commonly encounter, but are not generally listed on higher-level design fault lists.

Note: This article talks mostly from the perspective of a global web sites open to everybody. Of course, you might be developing your ASP.NET web applications for a very limited audience. In these situations, not every annoyance listed here might apply.

Ten Common, Six Smaller but Yet Annoying

If you do a quick search with Google, Yahoo!, or Live about web design, you might find lists such as those shown in Listing 1.

Listing 1: High-level web application design mistakes.

1. Not taking into account different browsers and operating systems.
2. Creating invalid (X)HTML code, and/or using deprecated tags.
3. Failing to bake security in from the start: not validating parameters, and allowing code injection.
4. Creating sites in Flash only (would apply to Silverlight sites as well).
5. Using tables for visual layout.
6. Trying to detect the browser version (incorrectly).
7. Using too many popup windows, which fail in many browsers.
8. Naming CSS styles after what they look like rather than what they represent (for instance, green_checkmark vs. feature_enabled in a feature comparison table).
9. Making a web page of fixed width, and then specifying it too wide.
10. Using JavaScript to move and resize browser windows.

Such general lists often mention that you should make sure your web application runs on all major browsers, generates valid HTML, and so forth. Of course, these are important rules. Nevertheless, sometimes the smallest of the annoyances irritate users most, and so you should not forget being a little pedantic and tackling even the smallest details.

Next, you will learn about six small mistakes that are easy to solve, yet are irritatingly common. These are summarized in Listing 2.

Listing 2: Those small, yet annoying mistakes often overlooked.

1. Failing to accept input with spaces, and not trimming spaces properly.
2. Using too much JavaScript.
3. Forgetting that other nationalities exist.
4. Disabling the backward and forward browser buttons.
5. Using browser windows and tabs the wrong way.
6. Trying to be clever with language and/or country-of-origin detection.

Getting the Little Things Right: Spacing

You can start with a concrete example of such small things. Say your web application accepts credit card payments by allowing the user to enter his or her credit card number and expiry date. However, it is quite common for such web shops to fail the credit card authorization if the user enters spaces between the credit card numbers.

In the worst case, the web application simply gives the user an error message such as “Invalid credit card number.” This can be very annoying, especially because the credit card itself has the number punched in groups of four digits.

To avoid this, you should develop your web application so that it accepts the card with or without spaces in the middle. The .NET String class contains a convenient Trim method, but this method only trims spaces from the beginning and end of the given string. What you need is a method that removes spaces from everywhere in the string.

Probably the simplest way to do this is to use the String class’ Replace method, like so:

string creditCardNum = " 1234 1929 5922   9289 ";
string trimmedNum = creditCardNum.Replace(" ", "");

If you are already using C# 3.0, you could even create a static extension method to the String class and name it, for example, TrimWithMiddle (note the this keyword in the parameter specification):

internal static class MyStringExtensions
{
   internal static string TrimWithMiddle(this string input)
   {
      string trimmed = input.Replace(" ", "");
      return trimmed;
   }
}

Then, you could call this method by using any string variable without the need to remember special utility classes: “creditCardNum.TrimWithMiddle()”.

Too Much JavaScript Is Too Much

Many web sites today would not function without JavaScript support enabled, and indeed many web sites benefit greatly from scripting. For example, things like complex interactivity, slick user interfaces, and rich-client like data validation often mandate the use of JavaScript.

However, JavaScript is prone to errors, and not all web browsers support it exactly the same way. There are hundreds of web applications out there that require JavaScript to be enabled, but still contain errors. In the worst situation, the user is filling his or her contact details on a shopping site, and then finds s/he cannot complete the order because the web site didn’t create valid JavaScript for his or her browser.

How would you avoid such failures? The solution is not to rely on JavaScript in key functions, such as order processing. JavaScript is a great aid, but make sure data validation (and so on) also happen on the server.

By default, ASP.NET applications support the combination of both JavaScript and server-side based data validation, but for sites that are more complex, you might need to write custom code. In these cases, it is best not to interfere with the normal form processing that web browsers do. That is, keep the buttons (the submit button in HTML parlance) as they are, and avoid the “not invented here” anti-pattern.

In ASP.NET web applications, a basic button (an instance of the System.Web.UI.WebControls.Button class) creates the following HTML code:

<input type="submit"
       name="MyButton"
       value="My Button"
       id="MyButton" />

If you need to verify at submit time that all mandatory fields are filled in, use the ASP.NET validator classes. An example of these classes is the RequiredFieldValidator class. If you enable its EnableClientScript property, ASP.NET will generate valid JavaScript code to do validation in the browser.

You also can use the validator classes at the server side to check whether the form fields had valid values by either using the page class’ IsValid property, or the similarly named properties on each individual validator class.