Silverlight Behaviors

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> {

    private string _buttonName;
    
    public string 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> {

    protected override void OnAttach() {
        AssociatedObject.KeyDown += OnTextBoxKeyDown;
    }
    
    protected override void OnDetach() {
        AssociatedObject.KeyDown -= OnTextBoxKeyDown;
    }
    
    private void 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 {

    public static readonly DependencyProperty CommitProperty =
        DependencyProperty.RegisterAttached("Commit", typeof(Form), typeof(DefaultCommit),
            OnCommitPropertyChanged);
    
    public static DefaultCommit GetCommit(TextBox textBox) {
        return BehaviorManager.GetBehavior<DefaultCommit>(textBox);
    }
    
    public static void SetCommit(TextBox textBox, DefaultCommit commitBehavior) {
        BehaviorManager.SetBehavior(textBox, commitBehavior);
    }
    
    private void 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.