Avoiding Annoying Mistakes in Your ASP.NET Web Applications, Page 2
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" />
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.
Remember, the World Is Round
The Internet is a serious test for proper globalization. It is easy to develop web applications that are focused on your own nationality, but it is much harder to make sure people from all nations would be able to use your web site, even if you would keep it in English.
Address details and phone numbers are good examples of globalization issues that you must keep in mind when writing web applications for public use. For example, many web sites allow the user to fill in a form, and then expect somebody from the company to contact the user.
It sounds easy enough to develop such a form, but sometimes, developers cannot resist the temptation to over-engineer. The classic example is the selection of state in contact detail forms. Very often the state is marked as a mandatory field, but not all countries have states. Similarly, phone numbers might be expected to be entered in a certain format—for example requiring a three-number area code when many countries around the world do not have it.
ASP.NET doesn't have a ready-made telephone number entering field; therefore, a regular textbox would do in most situations. In many cases, a simple textbox without too much formatting checks would work best. If you must make sure the format is correct, only accept for example numbers, spaces, parenthesis, and the plus sign in the number, nothing more. The .NET Regex class from the System.Text.RegularExpressions namespace is a good way to make sure the given input string is valid.
Failing to Support Backward and Forward Navigation
When comparing generic Windows applications and web applications, maintaining state and navigation is one key difference between these two application types. Web browsers allow the user to navigate backward and forward in the web pages they surf, and this happens to be the way web browsing is taught in schools and educational institutions.
However, from a web application design perspective, this backward and forward navigation can be an issue. The traditional example in interactive web applications (versus static pages) is the shopping cart: When you update the contents of the shopping cart, you will generally move to a new page. If you now click the back button on your browser, you will get the older page, which now displays incorrect information. Does the user realize that this just happened?
Thus, you should spend time designing how your application ought to work. In ASP.NET web applications, you can use the HTTP 1.1 protocol "Cache-Control: no-store" directive to specify that the browser must not cache the returned page, and instead must always refresh it from the server.
It is easy to add this directive to the server response by calling Response.Cache.SetNoStore in the ASP.NET page code (the older Response.Expires property has been deprecated), but this quickly leads to problems if you use the POST HTTP method (ASP.NET uses this by default for postbacks). However, for regular GET requests, the SetNoStore method works well, if you do not consider additional server load to be a problem.
That said, your basic rule of thumb should be not to interfere with the backward and forward buttons, unless confusion is likely to occur (think the shopping cart). GET requests work best, because the web browsers usually display a message box before navigating back to a POST page if the SetNoStore method has been called. It is also worth noting that the "Cache-Control" directive requires HTTP 1.1.
Incorrect Usage of Browser Windows and Tabs
Not so long ago, web browsers only had the notion of a single page, and the only option to display two or more web pages at the same time was to open new browser windows. This possibility quickly led to the popup window craze, and in turn created a lucrative business opportunity to sell popup blocker software.
However, with all the major web browsers now supporting tabbed browsing, it is time to adapt web applications accordingly. That is, many web sites still can open popup windows, when the user might have opted to use tabs instead. For example, in Internet Explorer 7, you can specify whether popup windows should be opened in windows or tabs.
The key thing is to let the user choose. If the user prefers tabs, do not force him or her to see popup windows. When creating HTML links, the A tag's target attribute is the key to specifying whether a link should open in a new windows or tab, depending on user's preferences. For instance, this link would open the target page in a new browser window or tab:
<a href="mywebform.aspx" target="_blank">Link to a popup window</a>
If you were to use the ASP.NET Hyperlink control, then you could write code like this:
MyHyperLink.NavigateUrl = "mywebform.aspx"; MyHyperLink.Target = "_blank";