Simple Search Panel in MVC 4

Introduction

This article provides a demonstration of implementing a search panel in an MVC project using little more than a bit of jQuery along with a couple of freely available plugins.

Figure 1 - Demo Project with Collapsible Search Panel

What you will need

In order to build this project you will need a copy of jQuery (or you can use a CDN) and the jQuery Cookie plugin. In order to run the demonstration you will also need a copy of the zip code database. The good news is that all of these things are included in the project. You will need to restore the zip code database from a backup to your local instance of SQL Server; check the download for a copy of the database entitled, "PostalCodes.bak". Of course you will also need a copy of Visual Studio or it won't be loads of fun looking at the files in the attachment.

Getting Ready

Start out by restoring the database to your local SQL Server instance; if you don't have one then you can download SQL Express or SQL Server Developer Edition free from Microsoft. Then unzip the project and open it up in Visual Studio 2012. You can then go into the web configuration file, locate the connection strings and update them to point to your local copy of the zip code database. At this point you should be able to run the project. If you would rather locate and download your own zip code or any other database to use instead of the demo database then feel free to swap it out for something more useful to you.

Demo Project

The project consists of a single MVC 4 application; aside from the usual boilerplate, the project contains a home controller along with a single Index view associated with that controller. It also contains a style sheet, the jQuery cookie plugin, and a couple of images to support a button with a hover effect. Not much to it all. There is an Entity Framework model (.edmx) that points to the database and a single accessor method to fetch the postal codes for display in a grid. Since the grid is a WebGrid, the project also imports the System.Web.Helper library as well. You can find the model and accessor class in the DAL folder in the project.

As far as filtering the data goes, everything that needs to be done happens entirely in the Index controller action. Whilst this is certainly not the most expeditious way to handle a large fetch, I think you will find that dealing with 42,000+ records, it is not what one would think of as terribly slow either. I would rather consider this a very quick and dirty way to set up a filtering mechanization without much bother.

The next figure (Figure 2) contains a look at the Solution Explorer for the project. The controller and view folders are open to show the home controller and index view that make up the working part of the demo application.

Figure 2 - Solution Explorer

Home Controller

With the project open in Visual Studio 2012, open up the Home Controller and have a look at the one and only controller action it contains: Index. In looking it over, you will see the first thing it does is call the accessor's method used to fetch the postal codes. If no filters were passed to the controller, then the results are not filtered at all. If any filters are passed in then they will be applied to the result set. Not overly efficient but not terribly slow either. You could write instead accessor methods that take each of the filter arguments as optional and return only the filtered results to the associated view, but this is quick and dirty; feel free to modify it or do it entirely with AJAX if you prefer.

So, if the method receives any filter arguments passed in then you can see the that code looks to see if the filter contains any content and if so, the controller applies that filter to the list of postal codes to limit what is passed on to the view. I mixed it up so that most use the expression as the basis for a StartsWith filter, with the latitude and longitude that made less sense than using Contains so I applied Contains to the latitude and longitude filters. I suppose you could provide the user an option to make it contains or starts with if you were so inclined; I wasn't.

Index View

The index view is a razor view that contains the markup and script necessary to format the view and manage the search panel. Since we are going back to the controller to filter the results and we don't want the search panel closing each time we do, I used the jQuery cookie plugin to keep track of whether the panel should be opened or closed and then set the panel accordingly. As with all things, you could use something other than the cookie to persist the opened/closed state of the panel if you prefer.

I also used the cookie for maintaining the position of the cursor for the same reason. When you select a filter TextBox or tab into one, each time the view is returned it will set the cursor into the last left text box. This prevents the cursor from returning to the start of the tab order each time the view returns.

The sum total of the view is contained in the code below; have a look below to see how the search panel is configured and then look to the script blocks at the end of it to see how jQuery was used to control the search panel visibility and the tab order.