A good menu structure usually only provides links to a subset of the site's overall content. Considering that it's realistic for an average-sized website to have hundreds of pages of content, it makes sense for a navigation structure to provide site visitors with links to only the most important and relevant items and not overload them with links to all possible resources. Search is a good way to provide access to the remaining items and also give an alternative to menu navigation for those who prefer it. The implementation section discusses how to develop a successful search strategy using Ektron's search technology, including the use of Web Analytics for tracking search terms site visitors use and tweaking results based on that data. The section also covers a deep look into Ektron Search and provides architectural diagrams and code samples showing how to leverage the search architecture.

Providing site visitors with navigation indicators that help them understand their current position in the overall information architecture of the website is another critical factor for ensuring a happy visitor and increasing page views. This chapter will show how to implement navigation using Ektron's Breadcrumb and Sitemap features.

Keep in mind that not all visitors to the homepage are first-time visitors. The homepage is visited by new users and existing membership users alike. It's a good idea to offer membership users the ability to log in directly from the homepage. This chapter also discusses ways to use Ektron's registration functionality, including both its native registration methods as well as its ability to integrate with Facebook Connect.

The first group pertains to the original designs of rich interfaces. A typical solution was to create a splash page, which might show a movie or some information before the users moved on to the site itself. This type of interstitial is widely regarded today as detrimental to the usability of the site, and is generally frowned upon.

The group of solutions that don't require additional data from the server today has grown to be more oriented towards producing a richer experience for the visitor. For instance, creating a client side sorted table through the use of JavaScript is a very typical interface requirement. Like many solutions requiring a richer sort of technology, this requirement can be solved through the use of a simple link that informs the server to render the page again with a different sort order. However, the modification to use JavaScript client side eliminates a round trip to the server. That round trip is a very expensive call, both in terms of wait time for the users, as well as in terms of server load, so eliminating the call is very desirable.

The second group of solutions — those that require returning to the server for more information in order to update the page for the users — first became common with the use of AJAX. Microsoft supplies a set of tools dubbed ASP.NET AJAX, which can simplify the development of these requirements through wrapping the calls back to the server in a standard framework that requires nothing of the developer except to wrap the portion of the page to be rendered again in an ASP.NET UpdatePanel Server Control. This solution provides a very simple way for developers to create a lighter feeling Web solution and in many cases is perfectly acceptable. However, using the standard Microsoft AJAX toolkit still requires a full-page lifecycle to occur on the server, even though only the updated portion of the page is returned to the user. This means that of the two downsides to using a standard anchor tag to update the page — the server render time and the client transfer time — only the transfer time is reduced; the server render time remains the same.

The use of Web services, or RESTful services, has increasingly become an accepted method for reducing both the bottlenecks at this point. While this solution is typically more complicated to develop, the decrease in server load can sometimes be a worthwhile reason for this approach. Any of the list of currently popular client side technologies allow for this mode of development. Additionally, ASP.NET makes it very easy to develop a simple Web handler that can respond in any format required.

This chapter covers two simplified examples to help you understand how best to approach these types of problems. The first example you will explore using the jQuery library to animate the slider on the homepage of the OnTrek website. The example starts by discussing the storage of content specific for the interface, allowing for benefits like localization and easy updating. You will then move onto generating appropriate output for the content to be displayed, and finally create some code to actually render the slider.

The second example is about the creation and consumption of RESTful generic handlers. For this example, you'll create a simple ASHX Web handler that responds to queries with JSON, and the authors will talk about consuming the results through the use of jQuery.

On the homepage of the OnTrek website, there is an image rotator at the top of the page. The images displayed, along with the accompanying text, all come from a settings content item stored in the CMS as Smart Form content based on the Rotating Ad Smart Form definition. You created that definition in the Smart Form section of Chapter 6. In this section, you will explore the following:

To create the custom XSLT, follow these steps:

This XSLT is as simple as it can be while achieving the goals set here. After the header information, there is a single template, which matches the root of the document. Inside that template, there is a containing div element, which is the root of the output. Then do a for-each on the panels contained in the root node. Each panel is contained in a panel div. The panel div contains several other elements, like an h1, a p, and an anchor. Each of these elements contains the corresponding data. The choose acts as a switch based on whether or not the current panel is the first panel. In the case that it is, you simply set the background-image CSS property on the element. If it is not the first panel, then set the background-image property, but also mark the panel as invisible. You will then use jQuery to animate between them.

XSLTs can be very complex; fortunately there are many resources for learning more about writing them effectively. One point to consider that may assist your development efforts is how to debug an XSLT in Visual Studio. While this is not foolproof, as the Ektron Framework's internal XSL Transform engine can switch between two types of engines, it can frequently help a developer figure out just what is wrong with the transform.

To debug an XSLT in Visual Studio, you need to have a file for the input XML, and a file for the XSLT:

Figure 7.3. FIGURE 7-3

Now that you have the XSLT you wish to use, you need to set up your code to use it. You created the first example in the file HomePageBannerSerialization.aspx. Now, follow these steps:

This JavaScript might be a little unfamiliar looking — you're using object oriented code for this. You can think of this in three chunks of code:

You've now created the image rotator for the homepage. This was a simple example of using JavaScript to create a richer interface than displaying static HTML would yield. A common need, however, is for the interface to dynamically update itself with fresh data based on user interaction.

Start by creating a Web Form called SimpleHandler.aspx. Create this at the root of the site. The purpose of this file is to list the taxonomy nodes that are children of a given node. In this case, you will use the Taxonomies/OnTrek Site Navigation node, which has an ID of 189 in the default OnTrek database. The page you create will have three main elements on it:

The code listing for SimpleHandler.aspx follows. In its current state it will display the ID of the clicked taxonomy node in the results div, as displayed in the following code snippet.

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
  <title></title>
</head>
<body>
  <form id="form1" runat="server">
    <asp:Repeater ID="repeaterItemList" runat="server">
      <ItemTemplate>
        <a href="#" class="taxonomyLink" onclick="return false;">
          <span style="display:none;" class="taxonomyId">
            <%#
              DataBinder.Eval(Container.DataItem, "TaxonomyId")
            %>
          </span>
          <%#
            DataBinder.Eval(Container.DataItem, "TaxonomyName")
          %>
        </a>
        <br />
      </ItemTemplate>
    </asp:Repeater>
  <div id="ItemResults">
  </div>

<script language="javascript" type="text/javascript">
    //initialization of the Taxonomy links.
    //We wrap it in the document ready so it only runs
    //after the entire DOM has been loaded.
    $ektron(document).ready(function() {
      if ("undefined" != typeof TaxonomyHandler) {
        //When the link is clicked, fire the
        //getTaxonomyItems handler.
        $ektron("a.taxonomyLink").click(
          TaxonomyHandler.getTaxonomyItems
        );
      }
    });

    //this will be our namespace for objects and functions
    //created for the handler example.
    if ("undefined" == typeof TaxonomyHandler) {
      var TaxonomyHandler = {
        getTaxonomyItems: function() {
          //this function will look inside the clicked link
          //to retrieve the id of the taxonomy item clicked.
          //It will then display the taxonomy id in the results div.
            var clickedAnchor = $ektron(this);
            var taxonomyId = clickedAnchor.find("span.taxonomyId").text();
            $ektron("div#ItemResults").html(taxonomyId);
          }
        };
      }
    </script>
  </form>
</body>
</html>

In the codebehind for the page, register the jQuery library to include it on the page, retrieve the children nodes using the API, and then databind the nodes to the repeater. This code is listed in the following snippet.

public partial class SimpleHandler : System.Web.UI.Page
{
  protected void Page_Load(object sender, EventArgs e)
  {
    //include jQuery library
    Ektron.Cms.API.JS.RegisterJS(
      this,
      Ektron.Cms.API.JS.ManagedScript.EktronJS
    );

    //set up objects we will use
    Ektron.Cms.API.Content.Taxonomy taxonomyAPI
      = new Ektron.Cms.API.Content.Taxonomy();
    Ektron.Cms.TaxonomyRequest taxonomyRequest
      = new Ektron.Cms.TaxonomyRequest();
    Ektron.Cms.TaxonomyData taxonomyData
      = null;

//initialize the taxonomyrequest object
    //whether to include items or just sub nodes
    taxonomyRequest.IncludeItems
      = false;
    //the taxonomy id to retrieve the children of
    taxonomyRequest.TaxonomyId
      = 189;
    //the language of the items we should retrieve.
    //set it to the currently selected language
    taxonomyRequest.TaxonomyLanguage
      = taxonomyAPI.RequestInformationRef.ContentLanguage;
    //the taxonomy type
    taxonomyRequest.TaxonomyType
      = Ektron.Cms.Common.EkEnumeration.TaxonomyType.Content;

    //get the taxonomy item and children
    taxonomyData = taxonomyAPI.LoadTaxonomy(ref taxonomyRequest);

    //ensure the result is good, and databind it to the repeater
    if (taxonomyData != null && taxonomyData.TaxonomyHasChildren)
    {
      repeaterItemList.DataSource = taxonomyData.Taxonomy;
      repeaterItemList.DataBind();
    }
  }
}

Now that you have a page that lists the nodes, the next step is to create the handler to retrieve the children content of a selected node. You do this by following these steps:

<%@ WebHandler Language="C#" Class="TaxonomyExampleService" %>
using System;
using System.Web;
using Ektron.Cms;
using System.Collections.Generic;

public class TaxonomyExampleService : IHttpHandler {

  //this class is marked with the DataContract attribute
  //to specify that it is serializable.
  [System.Runtime.Serialization.DataContract]
  public class TaxonomyItem
  {
    //the properties listed below store the relevant
    //data for a given piece of content.
    //each is marked as a serializable property.
    [System.Runtime.Serialization.DataMember]
    public long ItemID { get; set; }
    [System.Runtime.Serialization.DataMember]
    public string ItemName { get; set; }
    [System.Runtime.Serialization.DataMember]
    public string ItemQuicklink { get; set; }

    //the constructor takes all three properties to initialize the object
    public TaxonomyItem(long ID, string Name, string Quicklink)
    {

ItemID = ID;
      ItemName = Name;
      ItemQuicklink = Quicklink;
    }

    //this method takes a list of taxonomyitems and serializes it as one unit.
    public static string SerializeList(List<TaxonomyItem> itemlist){
      System.IO.MemoryStream memoryStream = null;
      string serializedList = ""; //the return value

      if (itemlist != null) //ensure the input is valid before continuing
      {
        //create the serialization object
        System.Runtime.Serialization.Json.
         DataContractJsonSerializer responseItemSerializer
          = new System.Runtime.Serialization.Json.DataContractJsonSerializer(
              typeof(List<TaxonomyItem>));

        try
        {
          memoryStream = new System.IO.MemoryStream();

          //serialize the object and then write it to the output string
          responseItemSerializer.WriteObject(memoryStream, itemlist);
          serializedList = System.Text.Encoding.Default.GetString(
                                  memoryStream.ToArray());
        }
        catch (Exception e)
        {
          throw new Exception("Could not serialize results", e);
        }
        finally
        {
          memoryStream.Dispose();
        }
      }

      return serializedList;
    }
  }

  //this class is marked with the DataContract
  //attribute to specify that it is serializable.
  [System.Runtime.Serialization.DataContract]
  public class RequestItem
  {
    //this attribute marks that this property should be serialized.
    //the attached property specifies the parent taxonomy node
    //of the requested children.
    [System.Runtime.Serialization.DataMember]
    public long TaxonomyID { get; set; }

//this static method will take the serialized requestitem
    //object and deserialize it
    public static RequestItem Deserialize(string serializedItem)
    {
      System.IO.MemoryStream memoryStream = null;
      //declare a new requestitem so we don't return a null object
      RequestItem requestItem = new RequestItem();

      if (serializedItem != null) // ensure the argument string exists
      {
        //create a new serializer object
        System.Runtime.Serialization.Json.
          DataContractJsonSerializer requestItemSerializer
          = new System.Runtime.Serialization.Json.DataContractJsonSerializer(
                                                     typeof(RequestItem));

        try
        {
          //get the bytestream for the serialized object
          memoryStream = new System.IO.MemoryStream(
                           System.Text.Encoding.Unicode.GetBytes(
                             serializedItem));
          //deserialize the object
          requestItem = requestItemSerializer.ReadObject(memoryStream)
                         as RequestItem;
        }
        catch (Exception e)
        {
          throw new Exception("Could not deserialize request", e);
        }
        finally
        {
          //ensure the memorystream gets emptied
          memoryStream.Dispose();
        }
      }
      else
      {
        throw new Exception("Request is null");
      }
      return requestItem;
    }
  }

  public void ProcessRequest (HttpContext context) {
    //we will return an empty string if there is a
    //problem retrieving the children.
    string serializedResult = "";
    List<TaxonomyItem> results = null;

    //deserialize the request
    RequestItem request = RequestItem.Deserialize(
                           context.Request["request"]);

//get the child content items
    results = GetChildren(request.TaxonomyID);

    if (results != null)
    {
      //serialize the results
      serializedResult = TaxonomyItem.SerializeList(results);
    }

    context.Response.ContentType = "text/plain";
    //write the serialized results
    context.Response.Write(serializedResult);
  }

  public List<TaxonomyItem> GetChildren(long taxonomyId)
  {
    List<TaxonomyItem> contentItems = new List<TaxonomyItem>();

    //set up objects we will use
    Ektron.Cms.API.Content.Taxonomy taxonomyAPI
      = new Ektron.Cms.API.Content.Taxonomy();
    Ektron.Cms.TaxonomyRequest taxonomyRequest
      = new Ektron.Cms.TaxonomyRequest();
    Ektron.Cms.TaxonomyData taxonomyData
      = null;

    //initialize the taxonomyrequest object
    //whether to include items or just sub nodes
    taxonomyRequest.IncludeItems = true;
    //the taxonomy id to retrieve the children of
    taxonomyRequest.TaxonomyId = taxonomyId;
    //the language of the items we should retrieve.
    //set it to the currently selected language
    taxonomyRequest.TaxonomyLanguage
      = taxonomyAPI.RequestInformationRef.ContentLanguage;
    //the taxonomy type
    taxonomyRequest.TaxonomyType
      = Ektron.Cms.Common.EkEnumeration.TaxonomyType.Content;

    //get the taxonomy item and children
    taxonomyData = taxonomyAPI.LoadTaxonomy(ref taxonomyRequest);

    //ensure the result is good
    if (taxonomyData != null
      && taxonomyData.TaxonomyItems != null
      && taxonomyData.TaxonomyItems.Length > 0)
    {
      //iterate over the results, adding converted
      //items to the contentItems list
      foreach (TaxonomyItemData item in taxonomyData.TaxonomyItems)
      {

contentItems.Add(
          new TaxonomyItem(
            item.TaxonomyItemId,
            item.TaxonomyItemTitle,
            item.TaxonomyItemQuickLink));
      }
    }

    return contentItems;
  }

  public bool IsReusable {
    get {
      return false;
    }
  }
}

Now you need to return to the SimpleHandler.aspx file to create the glue to retrieve and display these results. The first section you add to the SimpleHandler.aspx file is a div just below the repeater. This div is used by the JavaScript as a template for each item returned from the handler. There are other methods of handling this sort of templating, but we have found this method allows for the most flexibility to developers, and keeps the template as part of the HTML. The template then contains tokens that are replaced with the values from the handler. The HTML for the template is listed in the following code snippet.

<div id="ItemResults">
      <div id="ItemTemplate" style="display:none;">
        #ID#: <a href="#QUICKLINK#">#NAME#</a><br />
      </div>
      <div id="DisplayedItems"></div>
    </div>

Compared to the earlier version of this file, you modified the contents of the existing ItemResults div to contain a template container, as well as a div with ID DisplayedItems. This second div is what displays the results, rather than the outer div. The template div is styled to "display: none;" as it will not be displayed to the user.

Now you need to update the getTaxonomyItems method in the JavaScript to actually call the Web service, and update the displayed items div. The update JavaScript is listed in the following code snippet.

//initialization of the Taxonomy links.
//We wrap it in the document ready so it only runs
//after the entire DOM has been loaded.
$ektron(document).ready(function() {
  if ("undefined" != typeof TaxonomyWebService) {
    //When the link is clicked, fire the
    //getTaxonomyItems handler.

$ektron("a.taxonomyLink").click(
      TaxonomyWebService.getTaxonomyItems
    );
  }
});

//this will be our namespace for objects and functions
//created for the handler example.
if ("undefined" == typeof TaxonomyWebService) {
  var TaxonomyWebService = {
    getTaxonomyItems: function() {
      //this function will look inside the clicked link
      //to retrieve the id of the taxonomy item clicked.
      //It will then display the taxonomy id in the results div.
      var clickedAnchor = $ektron(this);
      //get the child span of the anchor-this contains the taxonomy id
      var taxonomyId = clickedAnchor.find("span.taxonomyId").text();
      //build the requestitem object
      var requestItem = { 'TaxonomyID': taxonomyId };
      //use the Ektron JSON library to serialize it
      //and build the complete object to send to the handler.
      var dataObject = { 'Request': Ektron.JSON.stringify(requestItem) };

      //use the jQuery ajax method to perform an ajax call to the handler.
      $ektron.ajax({
        url: 'taxonomyexampleservice.ashx',
        //this will cause jQuery to evaluate the return object as json
        dataType: 'json',
        type: 'POST', //the data should be sent as POST, not GET
        data: dataObject, //the ItemRequest object
        //the method to call when we get data back
        success: TaxonomyWebService.updateDisplay
      });
    },
    //the ajax method calls this when data is returned
    updateDisplay: function(data, textStatus, XMLHttpRequest) {
      //retrieve the template contents
      var template = $ektron("div#ItemResults div#ItemTemplate").html();
      //the string that will be built containing the html to display
      var results = "";
      for (var i in data) {
        //perform string replacements for each token with the content
        //of the results
        var tmp = template;
        tmp = tmp.replace(/#ID#/g, data[i].ItemID);
        tmp = tmp.replace(/#QUICKLINK#/g, data[i].ItemQuicklink);
        tmp = tmp.replace(/#NAME#/g, data[i].ItemName);
        results += tmp;
      }
      //update the displayed items div with the constructed html
      $ektron("div#ItemResults div#DisplayedItems").html(results);
    }
  };
}

The changes in the JavaScript start with the addition of the AJAX call. You are setting the dataType to JSON so the results are evaluated, rather than returned as a string. You are also passing the dataObject as the POST data. The dataObject is comprised of a simple object you created, which you used the Ektron JSON library to serialize. Remember that to use the Ektron JSON library, you need to include the JSON file. The following code when placed in codebehind for this page does this.

Ektron.Cms.API.JS.RegisterJS(
  this, Ektron.Cms.API.JS.ManagedScript.EktronJsonJS);

The AJAX method also has a parameter called success which accepts a method. This method is set to updateDisplay. The updateDisplay method handles the templating output. With these changes your example is complete.

The complete code for the SimpleHandler.aspx file is shown in Listing 7-6.

<%@ Page Language="C#" AutoEventWireup="true"
    CodeFile="WebService.aspx.cs" Inherits="WebService" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
  <title></title>
</head>
<body>
  <form id="form1" runat="server">
    <asp:Repeater ID="repeaterItemList" runat="server">
      <ItemTemplate>
        <a href="#" class="taxonomyLink" onclick="return false;">
          <span style="display: none;" class="taxonomyId">
            <%#
              DataBinder.Eval(Container.DataItem, "TaxonomyId")
            %>
          </span>
          <%#
            DataBinder.Eval(Container.DataItem, "TaxonomyName")
          %>
        </a>
        <br />
      </ItemTemplate>
    </asp:Repeater>
    <div id="ItemResults">
      <div id="ItemTemplate" style="display:none;">
        #ID#: <a href="#QUICKLINK#">#NAME#</a><br />
      </div>
      <div id="DisplayedItems"></div>
    </div>
    <script language="javascript" type="text/javascript">

//initialization of the Taxonomy links.
      //We wrap it in the document ready so it only runs
      //after the entire DOM has been loaded.
      $ektron(document).ready(function() {
        if ("undefined" != typeof TaxonomyWebService) {
          //When the link is clicked, fire the
          //getTaxonomyItems handler.
          $ektron("a.taxonomyLink").click(
            TaxonomyWebService.getTaxonomyItems
          );
        }
      });

      //this will be our namespace for objects and functions
      //created for the handler example.
      if ("undefined" == typeof TaxonomyWebService) {
        var TaxonomyWebService = {
          getTaxonomyItems: function() {
            //this function will look inside the clicked link
            //to retrieve the id of the taxonomy item clicked.
            //It will then display the taxonomy id in the results div.
            var clickedAnchor = $ektron(this);
            //get the child span of the anchor-this contains the taxonomy id
            var taxonomyId = clickedAnchor.find("span.taxonomyId").text();
            //build the requestitem object
            var requestItem = { 'TaxonomyID': taxonomyId };
            //use the Ektron JSON library to serialize it, and build the complete

            // object to send to the handler.
            var dataObject = { 'Request': Ektron.JSON.stringify(requestItem) };

            //use the jQuery ajax method to perform an ajax call to the handler.
            $ektron.ajax({ url: 'taxonomyexampleservice.ashx',
              dataType: 'json', //this will cause jQuery
                                //to evaluate the return object
              type: 'POST', //the data should be sent as POST, not GET
              data: dataObject, //the ItemRequest object
              success: TaxonomyWebService.updateDisplay
              //the method to call when
              //we get data back
            });
          },
          //the ajax method calls this when data is returned
          updateDisplay: function(data, textStatus, XMLHttpRequest) {
            //retrieve the template contents
            var template = $ektron("div#ItemResults div#ItemTemplate").html();
            //the string that will be built containing the html to display
            var results = "";
            for (var i in data) {
              //perform string replacements for each token with the
              //content of the results
              var tmp = template;

tmp = tmp.replace(/#ID#/g, data[i].ItemID);
              tmp = tmp.replace(/#QUICKLINK#/g, data[i].ItemQuicklink);
              tmp = tmp.replace(/#NAME#/g, data[i].ItemName);
              results += tmp;
            }
            //update the displayed items div with the constructed html
            $ektron("div#ItemResults div#DisplayedItems").html(results);
          }
        };
      }
    </script>
  </form>
</body>
</html>

Now visit http://localhost/OnTrek/simplehandler.aspx to see the completed page. As shown in Figure 7-7, the page first lists a set of links that correspond to the taxonomy nodes. When a user selects a link, the jQuery performs an AJAX call to the TaxonomyExampleService.ashx, where the request is deserialized and the child content is retrieved. The child content is then serialized and returned to the jQuery where it is evaluated and templated before being displayed as output.

Figure 7.7. FIGURE 7-7

The Flex Menu's most prominent feature is its ability to intelligently highlight submenu items, based on the page that is being visited, when the page is loaded. For example, if a site visitor navigates directly to a website's "product page," the Flex Menu can automatically expand and highlight the appropriate submenu item. This is an extremely valuable feature — consider the annoyance site visitors often experience while navigating through a website using a standard hierarchical left-hand menu, only to have it collapse with each click and page refresh. Without auto-expanding menus, the site visitors have less indication of where they are in relation to the rest of the site and may miss opportunities to discover related information.

All the configuration information that determines which menu item to select is defined in the Workarea and executed by the server control, and therefore requires no custom coding. The server control derives which item to select based on a set of conditions that take into account both the menu's configuration options defined during the menu creation process and the data available at the page runtime, such as the page being visited and the ID of the content item displayed. The "Working with Menus" chapter of the Ektron Reference Manual lists the complete set of these rules; there are nine in all. It's a good idea to read through the complete list available in the Reference Manual before working with the Flex Menu, but the first two in the list are included here to give an understanding of what the rules look like.

This type of processing continues through all of the nine rules listed in the Reference Manual. If a particular rule doesn't find a match, the processing continues to the next rule, otherwise it stops processing. Once all rules are executed, if no matches are found, the menu renders collapsed with no menu items selected. The processing rules are fixed and cannot be changed. However, the item that's selected is determined by your specific menu's configuration. The Flex Menu Server Control has a debug mode that logs information to help developers understand why the Flex Menu made a particular selection. The following steps describe the process of enabling this logging feature.

The last thing to cover on the Flex Menu is controlling its presentation. The recommended method for styling the Flex Menu is to use CSS. There are a number of samples available in the CMS400Developer starter site (~/CMS400Developer/Developer/Menu/FlexMenu/) showing different menu styles achieved by changing exclusively the CSS, including rendering the Flex Menu horizontally (as used in a header navigation menu) and vertically (as used on a left-hand navigation menu).

Modifying the markup produced by the Flex Menu Server Control is achieved through modifying an XSLT file. Keep in mind that the default JavaScript produced by this control expects its HTML markup to conform to a particular schema. So if you decide to modify the markup through the XSLT, you'll also want to write your own JavaScript for manipulating it. This also requires an understanding of the XML structure produced by the Flex Menu Server Control, which contains attributes noting things such as a particular item being selected. This approach is demonstrated as you implement OnTrek's global navigation menus.

There is much less to say about the second of the two menu server controls since the CMS Menu Server Control does not try to solve the problem of auto-expanding menu items, and as such, is much more simplistic in its implementation. The CMS Menu renders the menu structure into the page and provides the markup, CSS, and JavaScript for default click event handling. If you don't need the menu to open itself, this is the menu to use. This control also allows you to modify its markup by modifying its default XSLT. However, in this case, the XML is simplified since it does not contain the same markup elements to denote when a menu item is selected. The benefit of using this control is that there is little overhead since it does not auto-expand menus. The obvious drawback of using this control is that your site visitors need to drill back into the menu each time the page loads, or you will need to write your own expansion logic.

There are three CMS Menu Server Control samples included in the CMS400Developer Menu section. Two of them include JavaScript for their demos: One is the local file called CSSMenu.js, and the other is the Workarea file ~/Workarea/java/cmsmenuapi.js. Both of these files are short and only a few JavaScript functions. The third sample (menu.aspx) does not include any JavaScript and does not open or close; it renders fully open.

Now that you understand the basics of how to create a menu and how to render the menu on the site using either one of two menu server controls, let's go into more depth on the menu configuration options that influence which menu item is automatically selected when using the Flex Menu Server Control. Since the CMS Menu does not provide the auto-expanding capabilities of the Flex Menu Server Control, the Folder and Template Associations described next are ignored by the CMS Menu. You should know which type of menu you plan on using on your website prior to creating the structure in the Workarea, since one requires more configuration information than the other.

As discussed earlier, a menu can contain links to content items, library assets, external hyperlinks, or submenus. The Add Menu Screen in Figure 7-10 shows the fields available when choosing to add a new menu (or submenu).

Figure 7.10. FIGURE 7-10

The field values are described in the Table 7-2. The final two fields, Folder Associations and Template Associations, are described outside of the table.

The Folder Associations field and The Template Associations field are applicable only to the Flex Menu and provide it with the information needed by the Flex Menu to control which items are selected by default. Folder associations are used to instruct the menu to automatically expand when a user visits a page containing a content item that lives in the specified folders. For example, if you associate the menu to the /MainSite/Pages/Products folder, and a user navigates to any content item that resides in this folder, the Flex Menu automatically displays the items on the associated submenu. The template associations are used in a similar way. They allow you to instruct the menu to automatically expand when a user visits a page that uses the specified template. For example, suppose you have a template called ProductDetails.aspx that provides a detailed description for a given product, and you associate this template to the Products Menu. Any time a visitor travels to the Product Details template, the Flex Menu automatically displays the Products menu.

Designing your menu structure up front will help avoid a couple of painful pitfalls when working with the Flex Menu. These include creating nested associations that result in unexpected content from expanding, or creating impossible conditions that prevent any menus from expanding. If you run into such a situation, refer back to the steps described in earlier sections to enable its verbose logging.

The OnTrek website uses a persistent global navigation that displays in the header of each page on the site. The following steps walk through the process of creating a subset of the "Our Company" menu shown in Figure 7-11.

To create a new menu item via the Menus tab, follow these steps.

If you've installed the OnTrek Starter Site, the complete navigation structure will already exist in the database.

The global navigation of the OnTrek website is located in the header section of each page on the site. You will now use a single Flex Menu rendered horizontally and placed in the website's master page. This implementation will use a custom XSLT to modify the markup, and also use the jQuery Superfish plug-in to provide its styling and subtle animations.

Continuing with the thread of making all information accessible through search is using Ektron's Integrated Search to include content from an external repository. Integrated Search is a natural fit when you have directories filled with files such as unmanaged HTML or Word documents in the server's file system (or accessible through a virtual path) and want them included in the search index.

To include a folder in the search index, follow these steps:

Ektron's social networking functionality demonstrates how Ektron Search can be used to search for people, colleagues, and community groups. The CommunitySearch Server Control allows you to find users by name and customize user properties, such as what department you work in, or your favorite type of food. There are also APIs available for retrieving this type of information about users and groups; these are discussed in more detail in Chapter 10 along with the rest of the community framework.

Knowing what people are searching for and understanding whether their searches are successful are essential parts of establishing an effective search strategy. The first part of this is straightforward. Start by looking at what search phrases people are using to find information. Ektron's Search Phrase Report displays a unique list of all the terms entered by site visitors, along with a count representing the number of times a term was used in a search, sorted in descending order with the most popular search terms at the top of the list.

To find this report, do the following:

Determining whether a particular search was successful using the Search Phrase Report is not always easy. The crux of the issue is that it's close to impossible to determine whether a search is successful simply by identifying the search term and determining whether the searcher clicked on the result. This is because the search term alone does not give an accurate picture of a searcher's intent. Even still, there are a number of warning flags to look out for in this report that can indicate potential problems. These are discussed in detail in the following sections.

Figure 7.14. FIGURE 7-14

In Figure 7-15, you can see the Ektron Search Framework's overall architecture and process for crawling and indexing content.

The process begins on the left hand side of the diagram with the Ektron user authoring content either through the Workarea or directly on the website. This content item can be any type of managed content, such as a content block, structured Smart Form data, or document through a content API, server control, or widget. Through a CMS Extension (see Appendix A), the publish pipeline is modified to notify the Ektron Windows Service that new content has been pushed. The Ektron Windows Service then invokes a request for either a full or incremental crawl.

Figure 7.15. FIGURE 7-15

During the crawl, Search Server retrieves content by querying the database through the use of stored procedures — it does not spider the website in the way that public internet search engines do — and it is important to understand why. Crawling the database means that the search architecture has access to rich metadata, taxonomy, and other forms of structured information. This is an advantage that site search has over public search engines like Google, who are limited in this knowledge since all content is visible only through loosely structured HTML documents. It is because of this type of indexing that Ektron can provide faceted search on custom user properties.

The process of content indexing is performed using IFilters, which are components that understand how to handle a specific file format, such as Microsoft Word. The Ektron Framework is distributed with IFilters to handle all common file formats such as Office documents, text documents, Shockwave Flash files, and PDF documents. It's worth pointing out that IFilters can also index custom attributes on files. These attributes include the file level metadata you see when you right-click a file and choose Properties

In Figure 7-16, you can see the overall architecture and process for querying and retrieving information.

Figure 7.16. FIGURE 7-16

The process is as follows:

The Search Framework APIs follow the overall pattern established in the Framework API, which was introduced briefly in Chapter 1 and is covered more thoroughly as a whole in Appendix B. This section builds on this by presenting code samples that implement various search-driven use cases. The Ektron Dev Center also features a screencast highlighting the design goals of the Framework API, why it was introduced, and how to work with it here: http://dev.ektron.com/FrameworkAPI/. Although it isn't required, it is recommended that you look through Appendix B and watch the screencast before reading through these samples.

In this section, you look at a use case and see the constructs used to implement it. The following snippet implements a search that defines two filters:

These two filtering criteria are grouped together using the SearchCriteriaFilterGroup. Because the LocalOperation is set to AND, both of these filters must be true for a search result to be included in the set. So content with the title "the ektron corporation" would be included, but "ektron, inc." would not.

public void SearchTitleWithTwoFilters()
        {
            SearchServerContentCriteria contentCriteria =
              new SearchServerContentCriteria();
            ISearchCriteriaFilter filter1 =
            New SearchCriteriaFilter<string>(
                    SearchCriteriaContentFields.Title,
                    SearchCriteriaFilterOperator.Contains,
                    "ektron");
            ISearchCriteriaFilter filter2 = new SearchCriteriaFilter<string>(
             SearchCriteriaContentFields.Title,
             SearchCriteriaFilterOperator.Contains,
             "corporation");

            SearchCriteriaFilterGroup groupFilter =
             new SearchCriteriaFilterGroup();
            groupFilter.AddFilter(filter1);
            groupFilter.AddFilter(filter2);
            groupFilter.Condition = LogicalOperation.And;

            contentCriteria.AddFilter(groupFilter);
            contentCriteria.PagingInfo = new PagingInfo(10, 1);

            ContentSearchResponse response = SearchManager.Search(contentCriteria);
            string query = response.ExecutedQuery;

            OutPutResult(response.RelavantResults);

          Console.WriteLine("Query '{0}'...", query);
          Console.WriteLine("Showing results {0} - {1} out of {2}
",
             contentCriteria.PagingInfo.StartRow,
             contentCriteria.PagingInfo.EndRow,
             response.AvailableResultCount.ToString());
        }

You can also nest filter groups, which gives you the full ability to create complex, nested filter expressions. The PagingInfo object defines how many results are returned and the current page in the resultset. In cases where you are using search as an Application Search, you might only need to return three results. Setting the paging info object to 3 ensures that you're never returned more results than needed.

The Search Framework APIs are also permission aware. This means that the results returned are properly trimmed according to the content permissions granted to the site visitor. Developers have the ability to force an administrator level access mode in cases where you're looking to use the Search Framework APIs as a general purpose API for content information retrieval. The following show the enumeration values that can be passed to the Search Manager constructor to force the Search Framework API into administrator level access mode.

This approach is often used when search is used for dynamic page generation using search. This approach is also sometimes referred to as "application search" which is a term used to describe applications built using search's highly denormalized search catalogs as a delivery system, instead of the highly normalized SQL database.