Autocomplete Bundle FAQ


For some time we've been hearing alot of requests from customers to deliver guidance on building responsive web client applications utilizing ASP.NET AJAX. As a result of this feedback we had an exploratory phase where we looked at different patterns of building AJAX style applications. As part of our discovery we classified Web applications into one of 3 types with types 2 and 3 pertaining to AJAX style applications.
  1. Server side Web applications. Traditional web application whose pages are rendered on the server. Although client-side Javascript may be present for client side validation, the browser must invoke a full page postback in order to access data on the server.
  2. Pure RIA applications. A web application that performs most of it's rendering on the client rather than the server. AJAX is utilized heavily for accessing server side resources bwithout having to do a full post-back. The user interface rendering is then done client side through manipulating the DOM via Javascript libraries, or through a browser plug-in such as Adobe's Flash, or Silverlight. In the ASP.NET AJAX world, this means an application that makes little use of UpdatePanel and more heavily relies on the AJAX Extensions.
  3. Hybrid RIA applications. A traditional web application that renders both on the server and the client. On the client AJAX functionality is sprinkled throughout the interface in order to deliver a more responsive experience. In this kind of application partial-postbacks are common where the browser utilizes AJAX to post the page in an asynchronous fashion. The response to that post consists of HTML that is then dynamically updated on the client.
As we evaluated the different options we quickly determined that our focus should be on Hybrid RIAs rather than pure RIAs. The reasoning for this was several fold.
  • Customer's voted more heavily on how to AJAXize existing applications rather than creating pure RIAs
  • The tooling and developer productivity are lacking for building pure RIAs.
  • The ASP.NET team recommended based on their customer feedback that this should be our focus.

Why Autocomplete?

After completing this evaluation we then came up with an Order Entry Reference Implementation that would help us to flesh out customer scenarios around responsiveness. The reason we chose Order Entry is due to it's being a common type of LOB application that many developers have built.

As we build out the RI we noticed a few common challenges, one of which was around driving Reference Data to the UI. Reference Data is any data that is referenced as part of a transaction but which may not be transactional itself. In an LOB application this data may very large, and it is not practical to embed the entire list in a drop down. For example, imagine if each Order has an associated Customer and there are 20000 Customers. How is the user going to choose the Customer?
  • One option is to provide allow the user to click a search button, which takes the user to another page where they can search for the Customer. The Search page would allow you to type in a partial name to search on, and then returns paged results. Hitting the search page and scrolling through the result pages all require a server roundtrip. All and all this provides a functionality though highly inefficient method for locating the data due to all of the postback which result in delays and screen flicker.
  • A second option is to not provide any search functionality and simply validate the user's entry during the server roundtrip. This is also not efficient for large lists, because the user may not have the exact spelling. A hybrid of this would be to have logic on the server that automatically does a partial match if it does not find an exact match. In either case the amount of roundtrips makes this inefficient.
  • A third option (which we chose) is to implement the Suggestion pattern to provide a list of suggestions on the client dynamically based on matching against what the user has typed. This method has the advantage of removing the screen flicker and also reducing the amount of roundtrips and clicking.
For example as the user enters in 'New' for the City, they get back a list with items such as 'New York', 'New Jersey', 'New Castle', 'New Brunswick', etc. The Autocomplete extender included with the AJAX Control toolkit provides this functionality. Using the extender allows calling out to a Web Service to retrieve the list of suggestions. This works as long as the list does not need any additional filtering based on the UI. However, what if you want the City to be filtered based on the selected state, then this is a challenge? The more we looked at LOB application scenarios, the more we realized that this kind of scenario is quite common. For this reason we built the ContextSensitiveAutocompleteExtender which allows you to provide a list of related controls that provide additional context.

Why is there a dependency on ASP.NET AJAX

ASP.NET AJAX provides a rich set of functionality for buiilding AJAX style applications which this bundle leverages.

Why is there a dependency on the AJAX Control toolkit?

The new ContextSensitiveAutocompleteExtender inherits from the base AutocompleteExtender built in the AJAX toolkit. We did not see it practical to reinvent the wheel when the functionality has already been provided. The toolkit also provides an abundance of base functionality for building AJAX extenders.

What controls are supported for providing the context?

The new extender supports simple controls that contain a single Value / Text property. It will not support CheckBoxes, Option buttons, Multi-selectable combos, etc.

Can I use the Autocomplete bundle with the Web Client Software Factory?

Yes. The extender is within a reuable library that you can reference from your existing WCSF applications as long as the solution is properly configured to use ASP.NET AJAX and the AJAX Control Toolkit.

Can I use this with an existing ASP.NET Application that does not use CWAB.

Absolutely. The Autcomplete bundle does not have any dependencies on our factories. The extender is within a reuable library that you can reference from your existing ASP.NET applications as long as the solution is properly configured to use ASP.NET AJAX and the AJAX Control Toolkit.

Will it work with Visual Studio 2008 Beta?

We believe it will, but we are doing some additional testing which we will post on. Worst comes to worst we think customers would need to recompile the extender with appropriate .NET 3.5 references in VS2008.

Am I required to have GAT/GAX installed?

No, as there is no automation.

Can I get the source code?

Yes, as this is a CodePlex project, you can download it by clicking on the Source Code tab.

Last edited Sep 28, 2007 at 10:14 PM by blainew, version 7


No comments yet.