The UpdatePanel is the workhorse of the ASP.NET Ajax library. It is responsible for defining regions of a web page that trigger partial page postbacks (as opposed to full page postbacks). Such partial page postbacks transfer less information between the client and server and have their user interfaces updated seamlessly, thereby leading to a more interactive user experience. (For more information on UpdatePanels, refer to Using the UpdatePanel.) One side-effect of a partial page postback is that the HTML elements within the UpdatePanel are replaced with the markup returned on postback. This behavior is not noticeable and is not an issue unless you have client-side event handlers wired up to the elements within the UpdatePanel. Such client-side event handlers are lost after a partial page postback.

Consider a very simple UpdatePanel that contains just a TextBox and a Button. Furthermore, assume we have JavaScript on the page that creates an event handler for the TextBox's focus and blur events, which "highlights" the TextBox when the user focuses it and unhighlights it when losing focus. Initially, this script works as expected - clicking on the TextBox will "highlight" it. However, things break down once the Button is clicked. When the Button is clicked the UpdatePanel triggers a partial page postback and submits an asynchronous HTTP request back to the server. The requested ASP.NET page then goes through its life-cycle again, but this time only the markup in the UpdatePanel (and the hidden form fields on the page) are returned to the browser. The UpdatePanel then overwrites its existing markup with the markup just returned from the server. Unfortunately, this overwriting obliterates the focus and blur client-side event handlers, meaning that selecting the TextBox no longer highlights it.

In short, if there are client-side event handlers attached to HTML elements within an UpdatePanel it is imperative that they be rebound after a partial page postback. This article looks at three different ways to accomplish this. Read on to learn more!
Read More >

The .NET Framework provides a variety of classes in the System.IO namespace that simplify working with the file system. Using these classes it's possible to delete files and folders, to create new files, to edit existing files, and more. These classes, combined with ASP.NET's suite of Web controls and databinding syntax, make it quite easy to present information about the files on the web server's file system to visitors to your website. With a bit of markup and code, it's possible to add a simple file browser to a web page that allows users to view the files and folders from a particular directory on the web server. Such file browsers are useful if you let users upload content to the website and need to let them view their uploaded content. If you have a folder that contains user-accessible content like images, PDF files and Word documents, a file browser offers a quick and easy way for users to see what content is available and to view content of interest.

Back in 2003 I wrote an article titled Displaying the Files in a Directory using a DataGrid that showed how to list the files of a particular folder in a DataGrid Web control. This dated article still attracts a decent amount of traffic and questions from readers, so much so that I thought it worthwhile to update the content to use the latest technology, namely ASP.NET 4 and the GridView Web control. I also added some new features. For example, the file browser now lists both files and folders, allowing users to view the files in subfolders. Also, I moved the markup and code into a User Control, which simplifies adding the file browser to an ASP.NET page. This article walks through this new, updated version; the complete, working code is available for download at the end of this article. Read on to learn more!
Read More >

Last week's article, Implementing the Store Locator Application Using ASP.NET MVC (Part 1), started a two-part article series that walked through converting my ASP.NET store locator application from WebForms to ASP.NET MVC. Last week's article stepped through the first tasks in porting the store locator application to ASP.NET MVC, including: creating the new project; copying over stylesheets, the database, scripts, and other shared content from the WebForms application; building the HomeController; and coding the Index and StoreLocator actions and views.

Recall that the StoreLocator action and view prompts the user to enter an address for which to find nearby stores. On form submission, the action interfaces with the Google Maps API's geocoding service to determine if the entered address corresponds to known latitude and longitude coordinates. If so, the user is redirected to the StoreLocatorResults action (which we create in this article) that displays the nearby stores in both a grid and as markers on a map. Unlike the StoreLocator action created in Part 1, the StoreLocatorResults action uses a more intricate model and a strongly-typed view. Read on to learn more!
Read More >

Back in May 2010 I wrote a three-part article series titled Building a Store Locator ASP.NET Application Using Google Maps API, which showed how to build a simple store locator application using ASP.NET and the Google Maps API. The application consisted of two ASP.NET pages. In the first page, the user was prompted to enter an address, city, or postal code (screen shot). On postback, the user-entered address was fed into the Google Maps API's geocoding service to determine whether the address, as entered, corresponded to known latitude and longitude coordinates. If it did, the user was redirected to the second page with the address information passed through the querystring. This page then queried the database to find nearby stores and listed them in a grid and as markers on a map (screen shot).

Since the WebForms store locator application was published, several readers have emailed me to ask for an ASP.NET MVC version. I recently decided to port the existing WebForms application to ASP.NET MVC. This article, the first in a two-part series, walks through creating the ASP.NET MVC version of the store locator application and pinpoints some of the more interesting and challenging aspects. This article examines creating the ASP.NET MVC application and building the functionality for the user to enter an address from which to find nearby stores. Part 2 will examine how to show a grid and map of the nearby stores. Read on to learn more!
Read More >

One of the new controls available with ASP.NET 4 is the QueryExtender control. The QueryExtender is designed to simplify filtering data returned from a LinqDataSource or EntityDataSource by decoupling the filtering logic from the data source control. Using the QueryExtender is easy - simply add a QueryExtender to the page, specify what data source control it applies to, and then define the filtering criteria. For example, when displaying product information on a web page you could use the QueryExtender control and a few lines of markup to display only those products that are not within a certain price range and whose name or category starts with a user-specified search string.

Filtering the data returned by a LinqDataSource or EntityDataSource control is certainly possible without the QueryExtender; both the LinqDataSource and EntityDataSource controls have a Where property that can be used to specify filtering criteria. What the QueryExtender offers is a simpler means by which to filter data. This article includes a number of demos (which can be downloaded at the end of this article) that showcase the QueryExtender's ease of use and its powerful filtering capabilities. Read on to learn more!
Read More >

An enumeration is a special type in the .NET Framework that is comprised of a number of named constants. While you might not have created an enumeration type yourself, you have likely used enumerations many times in day-to-day programming. For example, the rows in a GridView have a RowType property that returns an enumeration of type DataControlRowType that indicates the row's type: Header, Footer, DataRow, and so on.

When working with an enumeration we may need to display a descriptive message based on the enumeration's value. For example, using ASP.NET's Membership system you can programmatically create a new user account calling the Membership class's CreateUser method. This method specifies the success or failure of the operation via the MembershipCreateStatus enumeration. This enumeration has members like Success, InvalidUserName, InvalidPassword, DuplicateUserName, and the like. When calling this method from an ASP.NET page you might want to show the user a descriptive message based on this enumeration value.

This article explores three different ways to provide descriptive text for enumeration members. Read on to learn more!
Read More >

Chances are, there are several different URLs that point to the same content on your website. For example, the URLs http://yoursite.com, http://yoursite.com/default.aspx, http://www.yoursite.com, or http://www.yoursite.com/default.aspx are all likely valid URLs that results in the same content, namely the homepage for yoursite.com. While having four different URLs reference the same content may not seem like a big deal, it can directly impact your website's search engine placement and, consequently, it's traffic. To a search engine, those four different URLs represent four different pages, even though the all produce the same content.

To understand how allowing duplicate URLs in your website can affect your search engine placement, first understand that search engines base a page's placement in the search results based, in part, on how many other websites link to the page. Now, imagine that there are 1,000 web pages from other websites that link to your homepage. You might conclude, then, that a search engine would rank the importance of your homepage based on those 1,000 links. But consider what would happen if 25% of those links linked to http://yoursite.com, 25% to http://yoursite.com/default.aspx, and so on. Rather than your homepage reflecting 1,000 inbound links, instead the search engine assumes there are only 250 links to http://yoursite.com, only 250 links to http://yoursite.com/default.aspx, and so on. In effect, redundant URLs can dilute your search engine ranking.

A key tenet of search engine optimization is URL normalization, or URL canonicalization. URL normalization is the process of eliminating duplicate URLs in your website. This article explores four different ways to implement URL normalization in your ASP.NET website. Read on to learn more!
Read More >

Search engine optimization, or SEO, is the practice of improving a website's position in search engines' results using unpaid techniques. The driver behind SEO is that a better (higher) position in the search results will, most likely, lead to more click throughs, increasing the website's visibility, audience, and profit. A previous article here on 4Guys, Search Engine Optimization Enhancements in ASP.NET 4, explored some of ASP.NET 4's new features designed to aid with SEO. Another helpful tool for SEO is Microsoft's SEO Toolkit, a free IIS add-on that you can run from your computer to inspect a local or remote website and identify potential issues that may impact its search engine rankings.

Using Microsoft's SEO Toolkit is simple. Once installed, run it and specify the website you want to analyze. The SEO Toolkit can analyze both local websites or remote ones. After you've specified the URL of the website to analyze, the SEO Toolkit will crawl the site, exploring its pages and identify potential issues that may affect the site's search engine rankings and offer suggestions on how to fix them. This article walks through getting started with the SEO Toolkit, showing how to use it and how to analyze its results and implement its suggestions to help improve your website's search engine placement. Read on to learn more!
Read More >