There are only two concepts you need to know for basic data binding. First is the concept of a binding expression. A binding expression is used inside the XAML of a Silverlight component to describe the name of the property that you want fetched from the model. A binding expression lives inside of curly braces ({ and }), and you can see three examples in the source code below.
###########################################################################################
<UserControl x:Class="DataBindingDemo.SimpleBinding" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> <StackPanel> <TextBlock Text="{Binding Name}" /> <TextBlock Text="{Binding Path=ID}" /> <TextBlock Text="{Binding Department.Name}"/> StackPanel> UserControl>
###########################################################################################
The first TextBlock in the XAML is using a binding expression on its Text property. The binding expression is telling Silverlight to pull the value for this Text property from the Name property of the model. The second TextBlock is fetching the ID property of the model using a slightly different (but equivalent) binding expression (the Path word is optional in simple expressions). You can even navigate an object hierarchy as demonstrated in the third TextBlock. In this case Silverlight will find a Department property on the model, then fetch the Name property from that object and use that for the Text property. All of the data binding options (such as the "Path”) are expressed as attributes inside the expression. We’ll see more options later in the article.
How does Silverlight know where the model comes from? That’s the second concept in data binding – the data context.
Most Silverlight controls will expose a DataContext property. By setting this property you are effectively telling Silverlight “here is the model to use”. Thus, the following C# code, combined with the above XAML, will produce the display shown to the right.
Employee employee = new Employee()
{
Name = "Scott",
ID = 1,
Department = new Department() { Name = "Engineering" }
};
this.DataContext = employee;
You can set the DataContext at anytime as long as the underlying Silverlight component is initialized. In the above code, “this” represents the user control, so we are setting the data context for the entire control, and all the TextBlocks inside will fetch values from the same model object. This is because Silverlight travels “up” the tree of controls to find the DataContext where a model exists.
For example, the {Binding Name} in the first TextBlock will first look at the DataContext on the TextBlock itself. When that fails to find a model there it will look at the DataContext of the StackPanel that is a parent of the TextBlock. When that fails, Silverlight will find the DataContext at the UserControl level. This “context inheritance” means we only need to set the DataContext once for the entire page and it flows downwards, but if need be we could also set multiple DataContext properties inside the tree of controls, and even override inherited contexts.
The first TextBlock in the XAML is using a binding expression on its Text property. The binding expression is telling Silverlight to pull the value for this Text property from the Name property of the model. The second TextBlock is fetching the ID property of the model using a slightly different (but equivalent) binding expression (the Path word is optional in simple expressions). You can even navigate an object hierarchy as demonstrated in the third TextBlock. In this case Silverlight will find a Department property on the model, then fetch the Name property from that object and use that for the Text property. All of the data binding options (such as the "Path”) are expressed as attributes inside the expression. We’ll see more options later in the article.
How does Silverlight know where the model comes from? That’s the second concept in data binding – the data context.
Most Silverlight controls will expose a DataContext property. By setting this property you are effectively telling Silverlight “here is the model to use”. Thus, the following C# code, combined with the above XAML, will produce the display shown to the right.
Employee employee = new Employee()
{
Name = "Scott",
ID = 1,
Department = new Department() { Name = "Engineering" }
};
this.DataContext = employee;
You can set the DataContext at anytime as long as the underlying Silverlight component is initialized. In the above code, “this” represents the user control, so we are setting the data context for the entire control, and all the TextBlocks inside will fetch values from the same model object. This is because Silverlight travels “up” the tree of controls to find the DataContext where a model exists.
For example, the {Binding Name} in the first TextBlock will first look at the DataContext on the TextBlock itself. When that fails to find a model there it will look at the DataContext of the StackPanel that is a parent of the TextBlock. When that fails, Silverlight will find the DataContext at the UserControl level. This “context inheritance” means we only need to set the DataContext once for the entire page and it flows downwards, but if need be we could also set multiple DataContext properties inside the tree of controls, and even override inherited contexts.
No comments:
Post a Comment