Building an AjaxPro.NET Based Search Engine into Your Website

Introduction

Generally, a search follows this rule: users enter some key words in the web page, and then click the "Search" button, and after a very short while the results will be returned. With the rise of Web 2.0 techniques, many local search engines have started to leverage AJAX. With the proper utilization of AJAX, information on web sites becomes more and more available and their capacities have also been greatly improved. In this article, I will show you how to embed a local search engine into an ASP.NET 2.0 website using two famous open source Ajax frameworks: AjaxPro.NET and AJAXSLT.

Author's Note: To follow along with the sample in this article, you're assumed to have installed Visual Studio 2005, AjaxPro.NET framework, and Google’s AJAXSLT framework. In addition, it is suggested that you download the source files accompanying this article.

Before delving into the main topic, let’s first examine several prerequisites that are necessary to constructing the local search engine.

AjaxPro.NET is a well-known open source framework. It is based on server-side techniques and provides support for constructing different versions of .NET web applications (whose download address is http://www.schwarz-interactive.de). The framework supports the server-side .NET SDK in several ways along with client-side JavaScript. It can direct JavaScript requests to the related server-side .NET methods, after which the server returns the newly-generated special JavaScript code to the browser. The framework's main functions and features are listed below:

1. Access the Session and Application data from the client-side JavaScript.
   
2. Cache the required results.
   
3. Freely use source code.
   
4. Add and modify new methods and properties in the framework without modifying any source code.
   
5. All the classes support the client-side JavaScript to return data, and DataSet can be used from inside JavaScript.
   
6. Use the HTML controls to access and return data.
   
7. Do not need to reload the pages and use the event delegates to access data.
   
8. Supply only one method for the complex invocation and therefore dramatically decrease the CPU usage.

Now, to use AjaxPro.NET in our ASP.NET 2.0 web sample application we should properly configure the web.config file. Since the downloaded materials have been shipped with a guide and an excellent Visual Studio Add-in (AjaxProVSTemplate.vsi), we are not going to talk much about the details of this framework. So, let's continue to focus on the next topic.

As is now well known, XML has become one of the standard formats for transforming, storing, and rendering data. Thus, we will not dwell on it here; instead, we'll discuss XSLT.

In fact, XSLT is a kind of language expressed as a well-formed XML document. However, the XSLT-defined elements are distinguished by belonging to a specific XML namespace (i.e. XSLT namespace).

In practical use, XSLT is responsible for transforming various kinds of popular data. Thus, an ".xslt" file defines a series of rules for transforming a source data tree into a result data tree. The transformation is achieved by associating patterns with templates. A pattern is matched against elements in the source data tree. A template is instantiated to create part of the result data tree.

The result data tree is separate from the source data tree. The structure of the result data tree can be completely different from the structure of the source data tree. In constructing the result data tree, elements from the source data tree can be filtered and re-ordered, and arbitrary structure can be added.

A transformation expressed in XSLT is called a stylesheet, and contains a set of template rules. A template rule has two parts: a pattern which is matched against nodes in the source data tree and a template which can be instantiated to form part of the result data tree. This allows a stylesheet to be applicable to a wide class of documents that have similar source data tree structures.

XSLT makes use of the expression language defined by XPath for selecting elements for processing, for conditional processing and for generating text.

XPath is the result of an effort to provide a common syntax and semantics for functionality shared between XSL Transformations and XPointer. The primary purpose of XPath is to address parts of an XML document. To support this purpose, it also provides basic facilities for manipulation of strings, numbers and booleans. XPath uses a compact, non-XML syntax to facilitate use of XPath within URIs and XML attribute values.

The primary syntactic construct in XPath is the expression. An expression matches the production Expr. An expression is evaluated to yield an object, which has one of the following four basic types:

• node set (an unordered collection of nodes without duplicates).
  
• boolean (true or false).
  
• number (a floating-point number).
  
• string (a sequence of UCS characters).

Putting aside the theories now, let’s consider a short example. The following illustrates a part of an ".xml" file which contains a reference to /category/items/category:

<category>

  <items>

<category name="popular">

<!-- The XPath expression matches this category node -->

...

</category>

<category name="extras">

<!-- The XPath expression matches this category node -->

...

</category>

  </items>

</category>

As you can see from the above snippet, a stylesheet is composed of rules. Each rule has a pattern which defines when it applies, and a template which defines what to output. Continuing with the example, here's a full rule defined in an ".xslt" file:

<xsl:template match="/category/items/category">

<div class="category"

  onclick="retrieveCategory('{@name}')">

<xsl:value-of select="@name"/>

</div>

</xsl:template>

When each node is reached, the template body is outputted. @name refers to the name attribute on the category tag. So when the related processing engine reaches the following XML segment:

<category name="extras">

  the following HTML will be output:

<div class="category"

  onclick="retrieveCategory('{extras}')">

   extras

</div>

The following HTML will be output:

<div class="category"

  onclick="retrieveCategory('{extras}')">

   extras

</div>

This wraps up the XML/XSLT discussion. Next, let’s continue with another interesting framework.

Generally, there are two ways for us to render incoming XML on the browser. Previously, XSLT has been used as a server-side technology—the server grabs some XML and creates a web page by transforming it into XHTML. More recently, browsers have incorporated XSLT functionality, so that the browser can create an HTML page by marrying an XML document with an XSLT stylesheet.

Browser-side XSLT is slightly different from that of the server side. In this case, the XML document does not constitute the contents of the entire page, but a response from an XMLHttpRequest Call. The transformation to XHTML can take advantage of the browser's built-in XSLT support, or alternatively an XSLT processor can be implemented in JavaScript, building on the browser's more primitive XML features. However, due to the complexity of XML and XSLT transformation, many developers are unlikely to implement it by themselves. Fortunately, there are a couple of good cross-browser libraries available, one of which is Google’s AJAXSLT, which has already been put into use in developing the famous Google Maps.

Now, let’s say a few more words about AJAXSLT.

First of all, we can download it from here. AJAXSLT is an implementation of XSLT in JavaScript—a browser-side solution. Because XSLT uses XPath, it is also an implementation of XPath that can be used independently of XSLT. This implementation has at least two advantages: it makes XSLT uniformly available on more browsers than natively provide it, and it can be extended to more browsers when necessary.

AJAXSLT’s implementation of XSLT operates at the DOM level on its input documents. It internally uses a DOM implementation to create the output document, but usually returns the output document as a text stream. The DOM to construct the output document can be supplied by the application, or else an internal minimal DOM implementation is used. This DOM comes with a minimal XML parser that can be used to generate a suitable DOM representation of the input documents if they are present as text.

The most important thing you should notice is that this framework also supports the aforementioned two ways of rendering XML on the browser—the browser side and the server side. For more flexibility, in this sample we will leverage the second solution. The ".xslt" stylesheet is stored under some sub folder of the web site while the "real" XML content comes from the database. For more details, please click on the link below and keep reading.

To give prominence to the search engine aspects of this article, we’ve simplified the database; it's  a Microsoft SQL Server 2005 database named Search_Data.mdf with only one table named article defined. The following Table 1 gives the structure for the article table.

Table 1—structure for the article table.

To gain a clearer understanding of the work flow, let’s sketch a rough map to illustrate the relationships between each of the modules, as depicted in Figure 1:

Figure 1—the general work flow used in implementing our search engine sample application.

As is shown in Figure 1, we’ve used the following routines:

1. Call two dummy methods (GetXMLFile and GetXSLTFile) from the client-side JavaScript. These two methods in turn call two Ajax methods defined on the server side via AjaxPro.NET to get back the XML and XSLT data, both in string format.
   
2. With the help of several APIs supplied by the client-side Ajax framework, namely AJAXSLT, we convert the XML data into HTML data in the specified format that has been defined using a special XSLT stylesheet.
   
3. Render the HTML data on the browser side.

Note in this example the server-side ".xslt" file is located under some sub folder of the website while the "XML" data are persisted within database table and later converted into an XML-formatted string.

This concludes part one. Please check back tomorrow for the conclusion to this tutorial.