End users often want the ability to sort information presented to them from a Web site. With the methods described in this article and accompanying download, developers can provide that functionality.
One of the most common uses of the Internet is to display information in a tabular format; examples of this include:
- Lists of events in date order.
- Contents of an article.
- Price lists.
In many of these situations, the users may want to sort the information presented to them in a different order than that initially provided by the Web site, for example, in alphabetical rather than date added order or first name rather than last name.
In this article, we will examine a few methods developers can use to provide this kind of functionality to the end user.
In its simplest form, a separate page could be created and maintained for each type of sort that the user may want to do, for example if you are providing a list of people as follows:
Then you could expect that your users would require the following sort orders on this data:
- First Name ascending alphabetically.
- First Name descending alphabetically.
- Last Name ascending alphabetically.
- Last Name descending alphabetically.
With such a small amount of data or content that is static for long periods of time, it is quite possible to create a separate page for each sort order, as can be seen in Demo1a in the accompanying demonstration download.
However, for larger, more complex or dynamic sets of information, this approach quickly becomes extremely resource intensive and difficult to maintain, so alternatives need to be found. In this article, we are going to break the alternative options down into three distinct sets:
- Server side - Those that are primarily reliant on server side functionality such as ASP, ASP.Net, Databases, etc.
The demonstration files located in this download should be extracted to the same directory. Some of the files require an ASP interpreter, Active X controls, or other server side Web software.
The array personArray is an array of objects, and begins unsorted. After the buildIndex function is run, the array is sorted in order of Last Name alphabetically. This can be seen in Demo 2, in the accompanying download.
The sorting itself is very quick, but what are we to do once we have sorted the data? We need to display it to the user, and there are two simple ways to do this:
The first example requires a post back to the server to get the current page again and then sorts it on load; the second example does this without the request to the server, and so is the better approach. This is the approach used on several sites including the Livelink Customisation Index page.
Another possible option is to publish the data into another tool—such as Microsoft Excel—in which the users may feel more familiar and in which the functionality to manipulate and sort data is significantly better. See the article, "Explore ways to pass a Microsoft Excel file to the client side," for a description of this approach or take a look at Demo 5 (which is IE-only and requires you to allow ActiveX controls to run).
Next we will examine a series of approaches that are primarily server side. For these examples, we shall use Classic ASP written in VBScript, although they could be quickly and easily converted into other languages. The most obvious approach here is to have the data stored in a database and then have the ASP page connect to the database, query it using an ORDER BY clause to get the order correct, and then simply display the output in an HTML table to the user. (See Demo 6) A Java Server Page (JSP) or PHP implementation of this code would be almost identical and perform with similar speed.
In addition to these "Interpreted" pages, we could use a compiled page. At the simplest level, this could be a VB DLL for use with a Classic ASP page or a Java Servlet for use with a JSP page. The following definitions of Interpreted and Compiled code explain the differences between them. Another option that is becoming increasingly common with developers is to use Microsoft's .NET Framework, one of the building blocks of which is the DataGrid control which can be seen in Demo 7.
Client and server side
In some cases, the client and server side can unite to deliver the functionality to the user; there are several methods of doing this, and we shall explore a few of them.
For example, in cases where the data volume is not significantly large and the connectivity between the client and the server is poor, or slow, then generating the initial data set on the server side and delivering it with the sorting code to the client side—where the sorting, if required, can occur—could be the most suitable solution, given the situation. An example of this can be found in Listing B.
Another similar option would be to replace the server side ASP with an XML file, which itself may or may not be generated from an ASP file, and then have the client-side sorting code interact with this in a similar way. In this method, only a single request, and not the entire page, is sent to the server side. An example of this could be the loading of an XML file containing moves for a Chess game that is then parsed and processed on the client side as shown in this example.
Some slight variations on the theme could incorporate the use of a new browser window to interact with the server side to get the data and then have it processed by the client side, such as the one shown in Demo 8. A similar approach can be taken using an IFrame, which could be hidden from the end user if required, as can be seen in Demo 9.
The options described above, allow us to sort the data and display it to the user, but which is the best tool for the job given a certain amount of data? The expectation is that for small sets of data, client-side processing would be significantly quicker than server-side processing, with the gap decreasing as the size of data rises and eventually, the server side approach becomes the more efficient.
To try and prove this statement, I took a data set containing a given number of records and then used the methods described above to sort them, recording the overall time—in seconds—from start to finish for each approach. The results are shown in Table A.
As you can see from the results, the time required for the client-side focused tests are steadily increasing, especially those which need a round trip to the server; for the others, the time remains relatively constant for such a small number of records. The ActiveX tests show a very good result, but it is using Excel's sorting functionality, which is designed to do this kind of sorting work. The .NET code also seems to perform well, which appears to be due to the fact that it is a compiled script, as opposed to Classic ASP's interpreted approach.
This article has offered several different methods for providing sortable datasets to the end user, some of which I hope will be new to the reader. As you can see, the results of the performance test clearly illustrate the range of records at which each approaches best performance. Bear in mind that these results may vary if you data which is more complex—e.g., has multiple people with the same or similar Last Name or has more columns which need to be manipulated.