F9 Group Marketing and Technology Blog

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 >

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.

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 ASP.NET Web Forms model strives to encapsulate the lower level complexities involved in building a web application. Features like server-side event handlers, the page lifecycle, and view state effectively blur the line between the client and the server, simplify state management, and free the developer from worrying about HTTP, requests and responses, and similar matters. While these facets of the Web Forms model allow for rapid application development and make ASP.NET more accessible to developers with a web application background, their behavior can impact your website’s behavior and performance. View state is perhaps the most important – yet most misunderstood – feature of the Web Forms model. In a nutshell, view state is a technique that automatically persists programmatic changes to the Web controls on a page.

As discussed in earlier installments of this article series – most notably in An Introduction to LINQ and The Standard Query Operators – one of LINQ’s primary components is its set of standard query operators . A query operator is a method that operates on a sequence of data and performs some task based on that data, are implemented as extension methods on types that implement the IEnumerable<T> interface . Some of the standard query operators that we’ve explored throughout the articles in this series include: Count , Average , First , Skip , Take , Where , and OrderBy , among others. While these standard query operators provide a great detail of functionality, there may be situations where they fall short. The good news is that it’s quite easy to create your own query operators. Underneath the covers query operators are just methods that extend types that implement IEnumerable<T> and iterate over the sequence performing some task, such as computing the total number of items in the sequence, computing the average, filtering the results, or ordering them. This article examines how to extend LINQ’s functionality by creating your own extension methods. Read on to learn more! Read More >

One of the most sure-fire ways to improve a web application’s performance is to employ caching. Caching takes some expensive operation and stores its results in a quickly accessible location. Since it’s inception, ASP.NET has offered two flavors of caching: Output Caching – caches the entire rendered markup of an ASP.NET page or User Control for a specified duration. Data Caching – a API for caching objects. Using the data cache you can write code to add, remove, and retrieve items from the cache. Until recently, the underlying functionality of these two caching mechanisms was fixed – both cached data in the web server’s memory. This has its drawbacks. In some cases, developers may want to save output cache content to disk. When using the data cache you may want to cache items to the cloud or to a distributed caching architecture like memcached .

Many websites that support user accounts require users to enter an email address as part of the registration process. This email address is then used as the primary communication channel with the user. For instance, if the user forgets her password a new one can be generated and emailed to the address on file. But what if, when registering, a user enters an incorrect email address? Perhaps the user meant to enter me@example.com , but accidentally transposed the first two letters, entering em@example.com . How can such typos be prevented? The only foolproof way to ensure that the user’s entered email address is valid is to send them a validation email upon registering that includes a link that, when visited, activates their account.

Over the past two weeks I’ve showed how to build a store locator application using ASP.NET and the free Google Maps API and Google’s geocoding service. Part 1 looked at creating the database to record the store locations. This database contains a table named Stores with columns capturing each store’s address and latitude and longitude coordinates. Part 1 also showed how to use Google’s geocoding service to translate a user-entered address into latitude and longitude coordinates, which could then be used to retrieve and display those stores within (roughly) a 15 mile area. At the end of Part 1, the results page listed the nearby stores in a grid. In Part 2 we used the Google Maps API to add an interactive map to the search results page, with each nearby store displayed on the map as a marker. The map added in Part 2 certainly improves the search results page, but the way the nearby stores are displayed on the map leaves a bit to be desired. For starters, each nearby store is displayed on the map using the same marker icon, namely a red pushpin. This makes it difficult to match up the nearby stores listed in the grid with those displayed on the map. Hovering the mouse over a marker on the map displays the store number in a tooltip, but ideally a user could click a marker to see more detailed information about the store, such as its address, phone number, a photo of the storefront, and so forth. This third and final installment shows how to enhance the map created in Part 2

Last week’s article, Building a Store Locator ASP.NET Application Using Google Maps API (Part 1) , was the first in a multi-part article series exploring how to add store locator-type functionality to your ASP.NET website using the free Google Maps API . Part 1 started with an examination of the database used to power the store locator, which contains a single table named Stores with columns capturing the store number, its address and its latitude and longitude coordinates. Next, we looked at using Google Maps API’s geocoding service to translate a user-entered address, such as San Diego, CA or 92101 into its latitude and longitude coordinates. Knowing the coordinates of the address entered by the user, we then looked at writing a SQL query to return those stores within (roughly) 15 miles of the user-entered address.