F9 Group Marketing and Technology Blog

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 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 .

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

Over the past couple of months I’ve been working on a couple of projects that have used the free Google Maps API to add interactive maps and geocoding capabilities to ASP.NET websites. In a nutshell, the Google Maps API allow you to display maps on your website, to add markers onto the map, and to compute the latitude and longitude of an address, among many other tasks. With some Google Maps API experience under my belt, I decided it would be fun to implement a store locator feature and share it here on 4Guys. A store locator lets a visitor enter an address or postal code and then shows the nearby stores. Typically, store locators display the nearby stores on both a map and in a grid, along with the distance between the entered address and each store within the area. To see a store locator in action, check out the Wells Fargo store locator . This article is the first in a multi-part series that walks through how to add a store locator feature to your ASP.NET application. In this inaugural article, we’ll build the database table to hold the store information. Next, we’ll explore how to use the Google Maps API’s geocoding feature to allow for flexible address entry and how to translate an address into latitude and longitude pairs. Armed with the latitude and longitude coordinates, we’ll see how to retrieve nearby locations as well as how to compute the distance between the address entered by the visitor and the each nearby store. (A future installment will examine how to display a map showing the nearby stores.) Read on to learn more! Read More >

Earlier this year I wrote an article about Twitterizer , an open-source .NET library that can be used to integrate your application with Twitter . Using Twitterizer you can allow your visitors to post tweets, view their timeline, and much more, all without leaving your website. The original article, Integrating Twitter Into An ASP.NET Website , showed how to post tweets and view a timeline to a particular Twitter account using Twitterizer 1.0. To post a tweet to a specific account, Twitterizer 1.0 uses basic authentication . Basic authentication is a very simple authentication scheme. For an application to post a tweet to JohnDoe’s Twitter account, it would submit JohnDoe’s username and password (along with the tweet text) to Twitter’s servers. Basic authentication, while easy to implement, is not an ideal authentication scheme as it requires that the integrating application know the username(s) and password(s) of the accounts that it is connected to. Consequently, a user must share her password in order to connect her Twitter account with the application. Such password sharing is not only insecure, but it can also cause difficulties down the line if the user changes her password or decides that she no longer wants to connect her account to certain applications (but wants to remain connected to others)

Twitter is a popular social networking web service for writing and sharing short messages. These tidy text messages are referred to as tweets and are limited to 140 characters. Users can leave tweets and follow other users directly from Twitter’s website or by using the Twitter API. Twitter’s API makes it possible to integrate Twitter with external applications. For example, you can use the Twitter API to display your latest tweets on your blog. A mom and pop online store could integrate Twitter such that a new tweet was added each time a customer completed an order. And ELMAH , a popular open-source error logging library, can be configured to send error notifications to Twitter. Twitter’s API is implemented over HTTP using the design principles of Representational State Transfer (REST) . In a nutshell, inter-operating with the Twitter API involves a client – your application – sending an XML-formatted message over HTTP to the server – Twitter’s website. The server responds with an XML-formatted message that contains status information and data. While you can certainly interface with this API by writing your own code to communicate with the Twitter API over HTTP along with the code that creates and parses the XML payloads exchanged between the client and server, such work is unnecessary since there are many community-created Twitter API libraries for a variety of programming frameworks. This article shows how to integrate Twitter with an ASP.NET website using the Twitterizer library, which is a free, open-source .NET library for working with the Twitter API. Specifically, this article shows how to retrieve your latest tweets and how to post a tweet using Twitterizer

XML is an increasingly popular way to encode documents, data, and electronic messages. There are a number of ways to programmatically create, modify, and search XML files. Since its inception, the .NET Framework’s System.Xml namespace has included classes for programmatically working with XML documents. For instance, the XmlReader and XmlWriter classes offer developers a means to read from or write to XML files in a fast, forward-only manner, while the XmlDocument class allows developers to work with an XML document as an in-memory tree representation. LINQ to XML is a new set of XML-related classes in the .NET Framework (found in the System.Xml.Linq namespace ), which enable developers to work with XML documents using LINQ’s features, syntax, and semantics. Compared to .NET’s existing XML APIs, LINQ to XML is a simpler, easier to use API. For a given task, LINQ to XML code is typically shorter and more readable than code that uses the XmlDocument or XmlReader / XmlWriter classes.

The Microsoft Chart Controls provide ASP.NET developers with an API and a Web control for creating and displaying charts in a web page. Behind the scenes, the Microsoft Chart Controls take the data to be plotted and dynamically generates an image. This image can be generated using one of three techniques: the Chart Web control can generate the image and save it to the web server’s file system in a specified location; the Chart control can generate the image and store it in memory, session, or elsewhere, and have that image served by a built-in HTTP Handler, ChartHttpHandler ; or the Chart control can send back the binary contents of the chart image directly to the browser. The chart image can be rendered using one of four image types: PNG , JPG , BMP , or EMF . And when rendering a JPG you can specify its compression level. Regardless of the image file type and the technique used to generate the image, the Chart Web control renders an <img> element whose src attribute references the image (or the image-producing HTTP Handler or ASP.NET page). When a browser requests a web page with a Chart control on it, it receives this <img> element as part of the page’s rendered markup and then makes a request to the URL specified in the src attribute (just like it does for any other image on a web page). The chart image file the browser requests either already exists in which case its contents are returned, or the image is dynamically-generated. Either way, the end result is that the browser is sent back the chart as an image file, which is displays. This article explores the three different techniques the Microsoft Chart Controls has at its disposal for generating chart images. We’ll look at how to use each option, enumerate the pros and cons, and discuss when to consider using one option over another. Read on to learn more! Read More >

A picture is worth a 1,000 words… This adage rings especially true when it comes to reporting. Charts summarize and illuminate patterns in data in a way that long tables of numbers simply cannot. Web developers have long searched for ways to express numerical data in a graphical format; until recently, doing so required the use of an open source or third-party charting or reporting package or some homegrown technique using HTML, GDI+, or some other technology. In September 2008 Microsoft released a free charting suite named Microsoft Chart Controls for the .NET Framework 3.5 SP1. The Microsoft Chart Controls are an encompassing set of charts for WinForms and ASP.NET applications. Despite being a first release, the Chart Controls suite offers a wide array of chart types and charting features. The Chart Controls offer all of the standard chart types – line charts, bar charts, pie charts, and so forth – as well as more specialized ones, like pyramid and bubble charts. The Chart Controls suite offers a comprehensive set of charting features, including support for multiple series, customizable legends, trend lines, and labels. And the Chart Controls API makes it easy to sort, search, filter, group, and export the chart data. Unfortunately, this first version of the Chart Controls has limited support for customizing the chart from the Designer. There are no wizards to guide you through customizing the chart’s look and feel and specifying its data source. Instead, you have to set the properties and bind the chart data yourself. While the Microsoft Chart Controls have some rough edges, their cost (free), number of chart types, and array of supported charting features make them an excellent choice for adding charts to an ASP.NET web application