AJAX In Action [191]
We can come up with an elaborate solution to this problem by adding an additional parameter to our custom object and sending it to the server. Another option is to work with what we have now so that we can make a minimum number of changes to our code. In this case, the simple solution involves changing one line in our code and adding an if statement on the server-side code. The goal is to be able to somehow differentiate between the elements on the server to determine which element has caused the postback. A simple way to tell the difference is to use the name that is on the element. In this case, we’ll reference the name of our textbox. In listing 10.20, we alter the parameter string to allow for this new functionality.
Listing 10.20 Altering the TypeAhead() function to allow for different queries function TypeAhead(xStrText){
var strParams = "q=" + xStrText + "&where=" +
theTextBox.obj.matchAnywhere + "&name=" + theTextBox.name; var loader1 = new net.ContentLoader(theTextBox.obj.serverCode,
BuildChoices,null,"POST",strParams);
}
By making the slight change to the variable strParams in the function TypeAhead(), we are passing the name of the textbox in the form parameters being passed to the server. That means we can reference this value on the server and use either an if-else or a case statement to run a different query. Now we do not need multiple pages for multiple elements.
10.5 Refactoring
Now that we’ve developed a fairly robust set of features for providing typeahead suggest capabilities, it’s time to think about how to package all of this functionality in a more palatable way for the consuming web developer. What Licensed to jonathan zheng Refactoring 393 we’ve developed to this point provides the functionality needed for the suggest behavior, but it has some drawbacks in terms of the work required for a developer to plug it into a web page—or 20 to 30 web pages, for that matter. So let’s imagine for a moment that we are the grand architect of an Ajax-based web framework and we’ve been assigned the task of writing a suggest component for the rest of the company to use. As the requirements-gathering meeting disperses, we’re handed a sheet giving us our loose set of functional requirements. Unsure of what we’re getting into, we glance down at the list (table 10.2). Table 10.2 Our functional requirements Number Requirement Description Priority 1 The component must work with existing HTML markup without requiring any changes 1 to the markup. Simple changes to the head section to inject the component’s behavior are acceptable. 2 The component must support being instantiated multiple times on the same page 1 with no additional effort. 3 Each component instance should be independently configurable, in terms of both 1 the behavioral aspects (e.g., case matching, match anywhere) and the CSS styling. 4 The component should not introduce any global variables. The company uses third1 party JavaScript libraries, and the global namespace is already cluttered. Any global names, with the exception of the component itself, are strictly prohibited. 5 The component should provide reasonable defaults for all of the configuration 1 options. 6 The component must work in IE and Firefox. 1 7 The component should use an open source framework to reduce the amount of cod1 ing effort required and improve the quality and robustness of the solution. 8 Oh, and if you can, get it done by the end of the week. 1 As we survey the list, several thoughts run through our head. Okay, first of all, the powers that be don’t seem understand the concept of a priority. But we’re fairly used to that, so we look to the heart of the matter—the requirements. And despite all our hard work, we’ve satisfied less than half of them. Our script is already done, so that satisfies number 7 in the sense that