The Adobe/Google announcement takes indexing one a step further beyond indexing static binary content, by attempting to simulate human behavior and interacting with the application to extract textual content and links from the application. I can see how automated clicks and the like might allow the crawler to cause an application to execute some partial logic, but a lot of application interaction is driven off of actual meaningful text input (eg. keywords in a search input box) where meaningful often depends on the specific application in question. The announcement does not go into any details... somewhat strange, I think, so there is naturally some guessing going on. The comment stream also contains a good mix of folks questioning whether the approach will even work? (for example here and here)

It is interesting to see the buzz - it is good to see search engines at least begin to think beyond indexing static HTML. Technically speaking, this sort of approach to indexability lends itself to Silverlight apps as well pretty easily. First a Silverlight application packaged in a xap file is easily cracked open without a special SDK - it is simply a zip file after all. Any static textual xaml content is easily parsed by virtue of being XML. Second it is easy to embed and extract metadata via an additional file within the zip archive. Third, the Silverlight DOM itself can be easily walked and inspected programmatically to detect all text, links and images that are being visualized by the control. Finally, it is possible to automate the application thanks to the extensible API that Silverlight offers for enabling accessibility and screen reader capabilties. Additionally, Silverlight apps can also support deep linking which is also important for facilitating relevance. Essentially, Silverlight provides simple APIs to allow the app to easily consume the URL it was loaded from, and use information on the URL query string to load and display appropriate data.

All that said, it will be interesting to see how well this approach pans out, as there are a number of challenges in simulating a user realistically, especially without any hints provided by the application developer. In the mean time, this is as good as any a time to share my slide deck on building indexable Silverlight applications that I used in my presentation at SMX, a search conference that took place last month here in Seattle.

The deck above illustrates the pattern for supplying alternate content with sample markup. At a high-level, the approach can be summarized as combining client-side logic with server-side rendering and sitemaps to address the "what" and "where" of indexability. The specific implementation of the pattern is interesting in how it achieves alternate content without requiring the developer to implement two applications and do double work.

I especially like the pattern because it works today, across search engines, applies to Silverlight/Flash apps as well as Ajax apps, and has a number of side-benefits around networking optimization and graceful degradation in script-less environments as listed in the deck above. Its always nice to pick a single pattern that can help solve multiple problems that Web developers encounter regularly. I first blogged about this approach back in 2007 right after MIX07. I had a chance to present it once more at MIX08, and you can actually check out the presentation and demo in the session video (skip ahead about 42 minutes into the talk for the part on indexability).

Any questions on the approach? Feel free to ask below. Also, I am curious what are your thoughts on the alternate content approach, or on the overall subject of search for RIAs?

DLR-based InvokeScript
So I got to work, and created an InvokeScript action (leveraging the extensibility of actions), and got this working:

          <
          Button
          Content
          ="Search"
          IsEnabled
          ="{Binding CanSearch}"
          >
          
            <
            vm:ButtonEvents.Click
            >
          
          
            <
            vm:InvokeScript
            Script
            ="$model.Search(searchTextBox.Text)"
             />
          
          
            </
            vm:ButtonEvents.Click
            >
          
          </
          Button
          >
        

The verbose XAML for defining parameters was gone, and I didn't have to create my own mini-language. However this is still too much XAML for me. With a bit more work, I was able to get the following syntax to work:

          <
          Button
          Content
          ="Search"
          
            vm:ButtonEvents.Click="$model.Search(searchTextBox.Text)"
          />
        

The InvokeScript does its work by hosting the DLR. As a DLR host the InvokeScript action is able to resolve things like $model to the current ViewModel instance. It also resolves "searchTextBox" when the script engine hits that. To do so, it first looks to see if it's a property of the Button (which it isn't, so it continues to search). Next it looks to see if it can find it in the visual tree using FindName or in the resources dictionary via a recursive FindResource (and it does find it in the tree). The bottom line is the script expression is simple and intuitive. And the DLR host does all the work through an intuitive set of rules, rather than have those be spelt out in a verbose form in XAML.This has me pretty satisfied.

As an aside, the script expression can also reference a variable named $event that represents the current event. This is useful if there is some interesting data in the event argument that you want to send across to the ViewModel operation (eg. mouse coordinates in a mouse event) or some property on the event argument you want to set by using the return value of the operation itself (eg. Canceled on a CancelEventArgs).

Essentially the InvokeScript action creates a little data flow pipe as shown below that flows event information and pieces of data from the View into the operation in the ViewModel. The pipe is also able to flow back the return value from the operation for use in the View, even though it hasn't been depicted here.

You might be wondering how the script engine is instantiated. This gives me a chance to introduce my framework's derived Application type that is used in App.xaml - XApplication. Amongst various other pieces of functionality, XApplication provides the semantics of being a global service container. The application developer can write this markup in App.xaml to declaratively define the instance of a ScriptService that will be used in their application. At runtime, the InvokeScript action looks for the current XApplication instance, and queries for the ScriptService service and uses the ScriptEngine that the service is responsible for instantiating and managing based on the specified language.

          <
          fxa:XApplication
          xmlns
          ="..."
          xmlns:x
          ="..."
          xmlns:fxa
          ="clr-namespace:Silverlight.FX.Applications;assembly=Silverlight.FX"
          >
          
            <
            fxa:XApplication.Services
            >
          
          
            <
            fxa:ScriptService
            ScriptLanguage
            ="JavaScript"
            />
          
          
            </
            fxa:XApplication.Services
            >
          
          </
          fxa:XApplication
          >
        

Note that you'll need to package the DLR assemblies (Microsoft.Scripting.*.dll) and the language specific ones (such as Microsoft.Jscript.*.dll for JavaScript) into your application's xap package. These are part of the Silverlight 2 SDK. Just add a reference to those dlls in your application project in Visual Studio and the XAP packager will do the right thing to include them in as part of the build process.

Code and Summary
As usual you can download the all of the code, sample, and framework to play with this to your heart's content. Do you think the use of DLR here helps signficantly simplify the view model pattern?

Implementing ViewModel via Action Behaviors
Both John Gossman and Dan Crevier have blogged about this pattern in the context of WPF, where their approach builds on data-binding and commanding. Silverlight supports a subset of data-binding features, but doesn't currently provide a commanding mechanism. Instead of commanding, I'll build the glue between the view and the operations defined in the view model via Actions (as you'll see in a moment) that are then hooked up via my behaviors framework.

Lets take a brief look at the implementation. I won't cover all the details, as you have the code and can step through as deeply as you'd prefer. On the right is my application's project structure.

I have my data model defined in the Data namespace. The Product class is an entity that has properties like Title, ImageUrl, ASIN etc. The Catalog class provides data access logic built by consuming the Amazon ECS REST APIs and the WebClient object that supports cross-domain networking. This code is pretty straightforward and commonplace. The catalog class implements the ICatalog interface. This has been defined so that the data access functionality can be mocked in a straightforward way for unit testing (more on that at the end).

The ViewModel is where it starts to get interesting. Being a developer, I'll start with that. It is defined in SearchView.model.cs as follows:

          public
          class SearchViewModel : Model {
    private IEnumerable<Product> _products;
    privatestring _keyword;
    privatebool _searching;

    publicbool CanSearch {
        get {
            return !IsSearching;
        }
    }

    publicbool IsSearching {
        get { return _searching; }
        private set {
             _searching = value;
             RaisePropertyChanged("IsSearching", "CanSearch");
        }
    }

    public IEnumerable<Product> Products {
        get { return _products; }
        private set { _products = value; RaisePropertyChanged("Products"); }
    }

    publicvoid Search(string keyword) {
        _keyword = keyword;
        Searching = true;

        Catalog catalog = new Catalog();
        catalog.SelectProducts(keyword, OnCatalogProductsSelected);
    }

    privatevoid OnCatalogProductsSelected(string keyword, Ienumerable<Products> products) {
        if (keyword != _keyword) { return; }

        Products = catalog.Products;
        Searching = false;
    }
}

The first thing to notice is that this class is completely independent from the UI. As such it can be tested quite easily. It simply represents a list of products, and the ability to perform a search that populates that list of products. It does this by consuming the data model.

This class derives from a class called Model from my framework, which supplies a default implementation of INotifyPropertyChange. The Model class also does some other nice things like cache PropertyChangedEventArg instances, and make sure change events are raised on the appropriate thread.

The next thing to implement is the view. Here you might imagine its is something that is worked upon predominantly and independently by a designer in Blend. The designer is free to choose the controls, lay them out, add animations and other subtle visual polish. As the UI comes together it might then be declaratively bound to the properties and methods that the developer has made available in the view model.

          <
          vm:View
          xmlns
          ="..."
          xmlns:x
          ="..."
          xmlns:vm
          ="clr-namespace:Silverlight.FX.ViewModel;assembly=Silverlight.FX"
          xmlns:app
          ="clr-namespace:AmazonSearch.Views"
          >
          
            <
            vm:View.Model
            >
          
          
            <
            app:SearchViewModel
            />
          
          
            </
            vm:View.Model
            >
          
          <
          Grid
          >
          <
          TextBox
          x:Name
          ="searchTextBox"
          />
          <
          Button
          Content
          ="Search"
          
            IsEnabled
            ="{Binding CanSearch}"
          
          >
          
            <
            vm:ButtonEvents.Click
            >
          
          
            <
            vm:InvokeMethod
            MethodName
            ="Search"
            >
          
          
            <
            vm:ElementParameter
            ElementName
            ="searchTextBox"
            ElementProperty
            ="Text"
            />
          
          
            </
            vm:InvokeMethod
            >
          
          
            </
            vm:ButtonEvents.Click
            >
          
          </
          Button
          >
          <
          ItemsControl
          ItemsSource
          ="{Binding Products}"
          >
          <
          ItemsControl.ItemTemplate
          >
          <
          DataTemplate
          ><
          app:ProductView
          /></
          DataTemplate
          >
          </
          ItemsControl.ItemTemplate
          >
          </
          ItemsControl
          >
          </
          Grid
          >
          </
          vm:View
          >
        

The view is implemented by deriving from View, which is in turn derived from UserControl. This is just for convenience. It adds the concrete notion of an associated Model that is assigned to the DataContext property so it is inherited by the contained controls.

The ItemsControl is bound to the list of products via vanilla data-binding already present in Silverlight.

The equivalent of commands are implemented using Actions. Actions are simply behaviors that can be attached to an element, via an attached property that provides event trigger semantics. In the sample, the ViewModel exposes a CanSearch property and a Search method that provide commanding-like semantics in a simple manner. The search button's IsEnabled property is bound to CanSearch, and its Click event is bound to the Search method.

I am not completely thrilled with the syntax, but this is perhaps the best that is doable, until the ability to define markup extensions becomes available in some future Silverlight version, and I might eventually be able to declare something like this instead:

          <
          Button
          Content
          ="Search"
          
            Click
            ="{Action InvokeMethod Search(searchTextBox.Text)}"
          
          IsEnabled
          ="{Binding CanSearch}"
          />
        

Actions are actually quite expressive since they are extensible and can encapsulate stock behaviors (the equivalent of stock commands). In the framework I have actions that work against storyboards (eg. PlayStoryboard), set properties etc. Here is another example of an action to perform the navigation whenever a search result is clicked.

          <
          Image
          Source
          ="{Binding ImageUrl}"
          >
          <
          vm:MouseEvents.MouseLeftButtonDown
          >
          
            <
            vm:Navigate
            NavigateUrl
            ="{Binding ItemUrl}"
            Target
            ="Amazon"
            />
          
          </
          vm:MouseEvents.MouseLeftButtonDown
          >
          </
          Image
          >
        

Unit Testing the View Model
One of the benefits of separation of concerns is easier testing of a greater portion of the application's code and functionality. Specifically, as the ViewModel is itself independent of the user interface, I should be able to easily unit test it.

Here I am going to leverage the Silverlight Unit Testing Framework to author tests for my ViewModel and then run them. This is also the place where I am going to leverage the fact that I defined an ICatalog interface earlier to represent my data access layer. For the unit tests, I am going to create a mock catalog implementation, that doesn't rely on making calls to the Amazon service.

Here is one of my mock catalog implementations that returns a dummy product.

          public
          class TestCatalog : ICatalog {
    publicvoid SelectProducts(string keyword,
                               Action<string, IEnumerable<Product>> productsCallback) {
        DispatcherTimer timer = new DispatcherTimer();
        timer.Interval = TimeSpan.FromSeconds(2);
        timer.Tick += delegate(object sender, EventArgs e) {
            Product testProduct =
                new Product {
                    ASIN = "1",
                    By = "TestAuthor",
                    ImageUrl = "http://www.example.com",
                    ItemUrl = "http://www.example.com",
                    Title = "Test Title"
                };

            productsCallback(keyword, new Product[] { testProduct });
        };
    }
}

And here is one of the tests defined in my test class. Note that I am using the ability to write async tests.

[TestClass]
publicclass SearchViewModelTest : SilverlightTest {

    [TestMethod]
    [Asynchronous]
    [Description("Test a typical search result.")]
    publicvoid TestSearchResult() {
        ICatalog mockCatalog = new TestCatalog();
        bool productsChanged = false;

        SearchViewModel viewModel = new SearchViewModel(mockCatalog);
        ((INotifyPropertyChanged)viewModel).PropertyChanged +=
            delegate(object sender, PropertyChangedEventArgs e) {
                if (e.PropertyName == "Products") {
                    productsChanged = true;
                }
            };

        viewModel.Search("xyz");

        EnqueueConditional(() => productsChanged);
        EnqueueCallback(() => Assert.AreNotEqual(viewModel.Products, null,
                        "Expected non-null products list."));
        EnqueueCallback(() => Assert.AreNotEqual(viewModel.Products.Count(), 0,
                        "Expected non-empty products list."));
        EnqueueTestComplete();
    }
}

Using the Unit Testing engine to execute my tests in the browser, i.e. running in the context of the Silverlight CLR, I see the following result, indicating goodness...

Summary
Hopefully this sample gave a good flavor of what the ViewModel pattern is all about, and how action behaviors can help create the bridge between the View and the ViewModel in Silverlight today. There are various other interesting discussion points and further exploration that relate to this, so stay tuned, but in the mean time I am curious what people think, and what questions arise as well, to help guide both the discussion, and the feature as its worked in into the framework.

Here's the corresponding server-side code implementing the service in Cities.ashx:

          public
          class CityCompletionService : CompletionService<string> {

    protectedoverride IEnumerable<string> GetItems(string prefix) {
        string[] matchingCities = ...;
        return matchingCities;
    }
}

Scenario 2: Styling the user interface
One of the most compelling aspects of XAML and Silverlight is the ability to create compelling user interfaces by restyling and reskinning controls to match the overall look and feel of your application. The AutoComplete behavior supports this by allowing you to specify a template for the dropdown used by the behavior. If I've got some customized look and feel defined in the myCustomListBox style, I can reference it as follows:

          <
          TextBox
          x:Name
          ="cityTextBox"
          >
          <
          f:Form.AutoComplete
          >
          <
          f:AutoComplete
          ServiceUri
          ="/App_Services/Cities.ashx"
          >
          
            <
            f:AutoComplete.DropDownTemplate
            >
          
          
            <
            DataTemplate
            >
          
          
            <
            ListBox
            Style
            ="{StaticResource myCustomListBox}"
            />
          
          
            </
            DataTemplate
            >
          
          
            </
            f:AutoComplete.DropDownTemplate
            >
          
          </
          f:AutoComplete
          >
          </
          f:Form.AutoComplete
          >
          </
          TextBox
          >
        

Scenario 3: Going beyond strings
So far the service backing the completion experience has been returning an array of strings. I actually want to use a service that returns something more than just a string (you'll see why in the next step). For example, in this scenario, I want to return an array of CityInfo objects that contain Name, State and ZipCode properties.

Here is the updated service implementation on the server.

          public
          class CityInfo {
    publicstring Name { get; set; }
    publicstring State { get; set; }
    publicstring ZipCode { get; set; }
}

publicclass CityCompletionService : CompletionService<CityInfo> {

    protectedoverride IEnumerable<CityInfo> GetItems(string prefix) {
        CityInfo[] matchingCities = ...;
        return matchingCities;
    }
}

In order to implement this scenario on the client I need to do a couple of things. First I need to provide a client-side type that the AutoComplete behavior uses to deserialize the JSON into. Next I'll want to customize the ItemTemplate of the ListBox to display the additional fields. Finally, I'll want to handle the Completed event to convert a CityInfo object into text that is used to put into the TextBox once a user selects a particular city.

          public
          class CityInfo {
    publicstring Name { get; set; }
    publicstring State { get; set; }
    publicstring ZipCode { get; set; }
    publicstring Location {
        get {
            return" (" + State + ", " + ZipCode + ")";
        }
    }
}

<TextBoxx:Name="cityTextBox"><f:Form.AutoComplete><f:AutoCompleteServiceUri="/App_Services/Cities.ashx"ServiceResultType="CityInfo"Completed="OnCityCompleted"><f:AutoComplete.DropDownTemplate><DataTemplate><ListBox><ListBox.ItemTemplate><DataTemplate><StackPanel><TextBlockText="{Binding Name}"/><TextBlockText="{Binding Location}"/></StackPanel></DataTemplate></ListBox.ItemTemplate></ListBox></DataTemplate></f:AutoComplete.DropDownTemplate></f:AutoComplete></f:Form.AutoComplete></TextBox>privatevoid OnCityCompleted(object sender, AutoCompleteCompletedEventArgs e) {
    // This event handler is optional. By default e.SelectedItem.ToString()// is used by the AutoComplete.e.SelectedItem = ((CityInfo)e.SelectedItem).Name;
}

Scenario 4: Filling dependent TextBoxes
There was a reason to return CityInfo objects instead of simply city names. Lets say my form also has a TextBox for entering ZipCode. If the user selects a city from the auto-complete dropdown, I'd also like to fill the zip code for added convenience.

I can simply update my Completed event handler above to extract the ZipCode and populate the ZipCode TextBox accordingly.

          private
          void OnCityCompleted(object sender, AutoCompleteCompletedEventArgs e) {
    zipCodeTextBox.Text = ((CityInfo)e.SelectedItem).ZipCode;
    e.SelectedItem = ((CityInfo)e.SelectedItem).Name;
}

Scenario 5: Using local computed values
So far I've been showing scenarios where the AutoComplete behavior makes a web request to get at the list of the completion items to show in its dropdown. Some times, an app might want to show a list of values computed in client-side logic. Or you may have already loaded data from a web service call, and just want to plug in that data, rather than making a separate call.

This scenario is implementable by handling the Completing event of the AutoComplete behavior which allows you to either plug in your items, or to suppress the dropdown altogether for the particular prefix text that the user has entered. For example:

          <
          TextBox
          x:Name
          ="cityTextBox"
          >
          <
          f:Form.AutoComplete
          >
          <
          f:AutoComplete
          
            Completing
            ="OnCityCompleting"
          
          />
          </
          f:Form.AutoComplete
          >
          </
          TextBox
          >
          private
          void OnCityCompleting(object sender, AutoCompleteCompletingEventArgs e) {
    string prefix = e.Prefix;

    string[] cities = ...; // code to lookup some local data using prefixe.SetCompletionItems(cities);
}

Live Demo
Finally, here is a demo of the AutoComplete behavior. To experiment, type in something "San" in the city TextBox to see a list of cities pop up. Select a city (such as San Francisco) to see both the city and the zip code TextBoxes get filled.

Yet another behavior... TextFilter
Actually, I've slipped in another behavior as well into the mix, just for some more fun. This is the TextFilter behavior that can also be associated with a TextBox to restrict input to say numeric characters.

          <
          TextBox
          x:Name
          ="zipCodeTextBox"
          >
          <
          f:Form.Filter
          >
          <
          f:TextFilter
          Filter
          ="Numbers"
          />
          </
          f:Form.Filter
          >
          </
          TextBox
          >
        

Hopefully these examples really start making the behavior concept more concrete, and clear.

You can download the code, which includes the behavior framework, all the behaviors I've written about so far, as well as a sample app that demonstrates using them. Enjoy!

Essentially the DefaultCommit behavior is attached to the TextBox using the XAML syntax above. For those new to XAML and Silverlight, f:Form.Commit refers to the Commit attached property offered by the Form class. This is similar to Canvas.Left, which you've probably encountered. The only difference is that the type of the Canvas.Left attached property is a simple double value, whereas the type of the Form.Commit property is a DefaultCommit.

Underneath the covers, the DefaultCommit behavior does the same thing you'd do in code-behind, but does so in a way that the logic is now encapsulated and is easily reusable. You can instantiate as many of these as you want, especially across multiple forms/pages without duplicating the event handling logic all over.

Here is a live demo (if you've got Silverlight installed) - simply type in something and press Enter. The app behaves as if you had clicked the button. There is no really search hooked up though.

You might have noticed the use of <f:Button> instead of a regular Button. Unfortunately, unlike WinForms and HTML buttons, the Silverlight Button control currently doesn't have any way to programmatically invoke the Click event, so I had to add that functionality in a derived class.

Implementing the DefaultCommit Behavior
The behavior framework I have put together introduces two classes Behavior and BehaviorManager.

The first step is to implement a behavior by deriving from the Behavior class. The Behavior class is a generic class, to allow indicating the type of objects that behavior can be associated with.

          public
          class DefaultCommit : Behavior<TextBox> {
}

The next step is to add any properties exposed by the behavior itself.

          public
          class DefaultCommit : Behavior<TextBox> {

    privatestring _buttonName;
    
    publicstring ButtonName {
        get { return _buttonName; }
        set { _buttonName = value; }
    }
}

The behavior base class holds the reference to the associated object as its AssociatedObject property. It defines a couple of abstract methods to manage the lifetime of a behavior instance: OnAttach, and OnDetach. The derived behavior class implements these to perform associated logic, such as setup and cleanup including subscribing and unsubscribing to events raised by the associated object.

          public
          class DefaultCommit : Behavior<TextBox> {

    protectedoverridevoid OnAttach() {
        AssociatedObject.KeyDown += OnTextBoxKeyDown;
    }
    
    protectedoverridevoid OnDetach() {
        AssociatedObject.KeyDown -= OnTextBoxKeyDown;
    }
    
    privatevoid OnTextBoxKeyDown(object sender, KeyEventArgs e) {
        if ((e.Key == Key.Enter) && (AssociatedObject.Text.Length != 0)) {
            Button button = AssociatedObject.FindName(_buttonName) as Button;
            if (button != null) {
                button.PerformClick();
            }
        }
    }
}

The final step is to define an attached property that can be used to declaratively create an instance of this behavior and have it be associated with a TextBox. This is where the BehaviorManager class will come into play. It provides a set of utility methods that correctly attach/detach behaviors.

          public
          static
          class Form {

    publicstaticreadonly DependencyProperty CommitProperty =
        DependencyProperty.RegisterAttached("Commit", typeof(Form), typeof(DefaultCommit),
            OnCommitPropertyChanged);
    
    publicstatic DefaultCommit GetCommit(TextBox textBox) {
        return BehaviorManager.GetBehavior<DefaultCommit>(textBox);
    }
    
    publicstaticvoid SetCommit(TextBox textBox, DefaultCommit commitBehavior) {
        BehaviorManager.SetBehavior(textBox, commitBehavior);
    }
    
    privatevoid OnCommitPropertyChanged(DependencyObject o, DependencyPropertyChangedEventArgs e) {
        BehaviorManager.UpdateBehavior(o, CommitProperty,
                                       (DefaultCommit)e.OldValue,
                                       (DefaultCommit)e.NewValue);
    }
}

There you go... writing a basic behavior is quite straightforward.

Concepts and Next Steps
One rough analogy to behaviors is that of extension methods in C# 3.0. Those are at the method level. Behaviors are similar, but are live components. More specifically, a behavior is a component that encapsulates some functionality and can be attached to another component to extend its built-in functionality, without creating a derived class. A couple of example behaviors that can be attached to a TextBox besides the one implemented above include auto-complete and input filtering.

The fact that behaviors are attached components that implies a composition-like metaphor, offers two advantages whenever derivation is non-essential:

• Allows "extending" multiple component types - in the TextBox example, the behaviors can be attached not only to TextBox but also to WatermarkTextBox.
• A single TextBox can be associated with multiple behaviors as needed, rather than requiring the developer to build and use a kitchen-sink style control that has to anticipate every possible feature.

Almost all behaviors handle events and encapsulate a set of event handlers into a reusable component that can then be instanced declaratively. Often this leads to a more declarative style of programming (something I love) and reduced code-behind clutter.

I chose a simple behavior scenario to introduce the concept. In a future post, I'll demonstrate some more interesting behaviors, including AutoComplete , and some animation scenarios. Stay tuned. Over time, I'll continue to experiment with this. I have some ideas on implementing declarative views that are enabled via this concept.

I'd love to hear ideas you might have for behaviors that would be useful additions for Silverlight and XAML-based UI, and especially for RIA scenarios.

You can also download the code which contains the behavior framework, the sample behavior, and a sample app that makes use of them.

In the demo, I wrote a simple template engine, which I can use by to rewrite the script as follows:

            <
            div
            id
            ="bookmarkList"
            >
            <
            ul
            id
            ="itemContainer"
            ></
            ul
            >
            </
            div
            >
            
              <
              div
              id
              ="bookmarkTemplate"
              style
              ="display: none"
              >
              <
              ul
              id
              ="itemContainer"
              >
              <
              li
              ><
              a
              href
              ="{Url}"
              >{Title}</a></ul></div>
            <
            script
            type
            ="text/javascript"
            >
            function fetchBookmarks() {
    // Issue an XMLHTTP request to retrieve user's bookmarks.
}
function onBookmarksAvailable(bookmarks) {
    // Update display using retrieved bookmarks. Each boomark has Url and Title properties.var template = new Templating.Template($get('boomarkTemplate'));var itemContainer = $get('itemContainer', $get('bookmarkList'));

    for (var i = 0; i < bookmarks.length; i++) {
        var item = template.createInstance(bookmarks[i]);
        itemContainer.appendChild(item);
    }
}
</script>

The interesting lines are in bold. The template is defined using regular XHTML markup representing how items should appear. This can be independently edited/designed and previewed. You simply embed atomic tokens such {Url} etc. into the markup.

The script is responsible for creating the template, which effectively generates the script equivalent, (this is done once), and then as the script loops over the list of bookmarks, it uses the template to create new instances of the list items and anchors, and adds them into the DOM to generate the display.

With this we have a client-side templating mechanism. However web development is all about balancing and meeting several requirements (at once). In particular here are some of the things I also want to tackle as a developer.

• Search Engine Optimization: Ideally the page rendered by the server isn't blank from the perspective of the search engine. I demonstrated a solution in my Ajax and SEO post over year ago.
• Optimizing Networking: I don't want to spend one connection downloading a blank page, and then immediately having the script turn around to issue another connection to fetch the first page worth of data.
• Reducing Page Load Time: Sending a blank page implies some delay as scripts are downloaded, loaded and data is loaded and processed to show data to the user. This should be avoided if at all possible.
• Script-disabled browsers: If targeting an audience that might have script disabled (this is perhaps a shrinking number), then being able to still deliver a degraded but functional experience is nice.

These can be addressed through some form of server-side rendering, sort of how you've been doing using server-side data-bound controls for years. The goal however, in the context of Ajax, is to leverage a single template definition for both server-side and client-side processing. This is where server controls really shine. They allow you to do Ajax better by providing end-to-end solutions.

I've written an AjaxRepeater server control as part of the prototype. It does server-side data-binding (using the same token format we've seen above), renders the list on the server, but also generates a client-side Repeater control (using the ASP.NET Ajax UI pattern for writing controls). The client-side Repeater control consumes the same template definition, and provides the ability to dynamically add rows on the client, or reset the list of items to be displayed. The sample below illustrates using this control, along with both server-side code and client-side script working against it.

            
              <
              n:AjaxRepeater
              runat
              ="server"
              id
              ="bookmarkList"
              >
              <
              ul
              id
              ="itemContainer"
              >
              <
              li
              ><
              a
              href
              ="{Url}"
              >{Title}</a></ul></n:AjaxRepeater>
            <
            script
            runat
            ="server"
            >
            void Page_Load() {
    bookmarkList.DataSource = new Bookmark[] {
            new Bookmark { Title="...", Url="..." }, ...
        };
    bookmarkList.DataBind();
}
</script><scripttype="text/javascript">function addBookmark(title, url) {
    var bookmark = { Title: title, Url: url };
    $find('bookmarkList').addDataItem(bookmark);
}
</script>

The current implementation is pretty much based on what can be done via String.Format to perform substitutions of tokens in the template with actual data (I used a tweaked version of James' FormatWith code). Eventually the hope is to productize this feature, and at that point we'd like you to be able add expressions in the template as well as express conditional segments within the template. For example, one might be able to write this:

            <
            n:AjaxRepeater
            runat
            ="server"
            id
            ="bookmarkList"
            >
            <
            ul
            id
            ="itemContainer"
            >
            <
            li
            >
            <
            a
            href
            ="{Url}"
            class="{ IsShared ? 'bookmark shared':'bookmark' }">{Title}</a><!--- if (!IsShared) { ---><buttontype="button"onclick="...">Share</button><!--- } ---></li></ul></n:AjaxRepeater>

As we extend the functionality of those templates, it is important to preserve the server-side rendering capabilities. One way to accomplish this is to use the DLR and JavaScript on the server. This can actually be done quite efficiently by doing the script-generation and compilation using the DLR at page parse time, once for the lifetime of the application, in much the same way that regular ASP.NET template markup is parsed and compiled once into a delegate that can be invoked multiple times. For ongoing prototyping at this moment, I am starting to look at JScript.NET, until the DLR is part of the framework.

One key realization here is that targeting the mainline scenarios that Ajax developers encounter all the time keeps the overall solution simple and elegant for both the developer and the framework. Combining that with the right server-side support makes the solution much more interesting, as it starts to address the end-to-end scenarios with a single set of concepts and a consistent approach.

I'll reiterate that this is a prototype that I partly demo'd at MIX, and isn't meant to represent exactly what might eventually make it into the product (as we all know, things change as we iterate on ideas, and put together feature plans)... but as I mentioned earlier, if you do have thoughts you'd like to share, then go ahead, and post them below.

For those who are interested at poking around in the code for either the templating engine (which is really quite small), or the server-side control, you can download the prototype as it exists today. If you delve in deeper, you might also notice that the included script was generated using Script# (as you might have come to expect of me by now) and comes along with the originating C# source as well. If you haven't installed Script#, then simply ignore the 2nd project in the solution when it prompts you. I am hoping to get a client-side templating engine added to Script# as well a little further down the road.

Reach and Rich
The diagram represents a spectrum of application development approaches and technologies/platforms with increasing reach on one end, and increasing capabilities on the other. Applications have distinct scenarios and correspondingly gravitate toward a sweet spot. Some apps lie squarely on the left, with the need to first and foremost prioritize universal reach. At the same time, some apps have experience or functionality as the high order bit, where it is necessary to leverage a more capable platform, even if it means somewhat reduced reach. Still, the best apps will probably be those that leverage multiple front-end options to follow the user, with a common back-end (sort of a software and a service model).

One thing is sure - users are expecting more, and apps are trying to differentiate by meeting them. For example, the Ajax hype has given way to broad mainstream and pragmatic use of the technology (hence I call the older style of Web apps as "Classic" in the diagram).

RIA Islands
At the same time, the reality is a number of applications are no longer "pure" Ajax, i.e. just HTML and Script-based. Ajax applications are increasingly relying on plugins such as Silverlight, Google Gears, and Flash to incrementally enrich the experience they can offer (ideally, in a manner such that they gracefully degrade). These plugins let Ajax applications do interesting things like use local storage, access user's files, integrate rich media and vector graphics, background processing etc. Just like ASP.NET server controls make it quite easy to incorporate Ajax functionality, they are also nicely positioned to simplify the "Islands of Silverlight" scenario. Imagine a data-bound server control that renders a Silverlight chart, and degrades to a static image dynamically rendered on the server without requiring the app developer to learn several new technologies. I've spoken on this at recent conferences, and will be blogging more on this end. Wilco blogged about Silverlight Interop to cover the use of Silverlight to implement HTML code-behind and creating a better file uploader for Ajax apps.

Trends
The second thing that is also interesting about the diagram are the trends in effect. The reach platform, starting to be referred to as the Open Web by some, is bound to get richer in terms of the execution engine, the presentation stack, and its framework capabilities. HTML 5 promises to improve some core pieces of the browser-based platform, and all the browsers (yes, that includes IE) are already stepping up to improving the state of the art in their next versions. The interesting question is when we will see ubiquity around the next batch of incremental improvements like the ubiquity of XMLHTTP that fueled the Ajax wave a couple or so years ago. RIA technologies are becoming more ubiquitous, and starting to become a viable or required choice for development in the next generation of Web apps. Over time as what is considered "rich" today gets commoditized by the reach platform, the platforms on the right need to constantly redefine themselves by finding new ways and value offerings in order to differentiate, which always keeps them interesting and in the forefront. It's a constant tug-of-war ... and it doesn't seem like either Ajax or the RIA approach is going to all out win any time soon.

A .NET Theme
So if you agree, the world isn't Ajax vs. RIA, but is rather Ajax and RIA (and Desktop), and there is room for them to co-exist, the final thing I'll point out is how the Microsoft platform plays out in this space. Clearly, the consistent theme across the board is .NET and managed code, which allows developer skills, as well as in many cases, common code that can be shared and leveraged as apps transition or grow. Ray Ozzie spoke to this when referring to connected development at MIX 08. We have .NET on the server providing that common backend, .NET on Web/Ajax front with ASP.NET and even . NET-flavored scripting with technologies like Script#, and of course, .NET on the client with WPF. Silverlight 2 brings .NET to the RIA space. In fact, the simple introduction of managed code into the browser is perhaps one of the most eagerly anticipated feature.

The fun, and simultaneously challenging thing, is working on the multiple sweet spots along the current application platform spectrum, balancing the feature set, and making sure we have messaging for how they evolve, complement, and differentiate to address specific scenarios at the same time.