In my previous blog we looked how easy it to use dynamic / ExpandoObject in Silverlight. But if you notice the sample code, I cheated big time there. Even though I created a dynamic class on the fly, the binding did happen to a known properties of the ViewModel. Have a look at the XAML I used in the previous example
You can see I am binding to a known fields FirstName, LastName, etc. If we were using dynamic classes these properties might not have been known during the design time so I couldn’t have bind the way I am binding here. So I cheated just to show how to create a dynamic objects but not the dynamic binding. Lets first try to bind to dynamic object itself and see what happens. To do that, I am going to change the XAML to bind to list of objects, whose properties are not known during design time (even though I am going to create them in code behind).
I am using ComponentOne FlexGrid to bind to list of Person to the grid. Now the ViewModel code which returns the People
With this code, if you compile and run, you will notice, it will not display any rows. So there is something wrong here. When I search the net, I ran into a forum posting on the same subject. So as per Min-Hong,
“I am afraid, it is beacuse dynamic does not support reflection.
Thus does not support databinding(in silverlight databinding uses reflection).”
I did couple of searches and hit a Silverlight feature list voting page on Microsoft, where lot of people requested this. It turned out, Silverlight 4 does not support this feature and I am not sure the state of Silverlight 5. But the good news is that, there were couple of work around to this problem. They are
- Using emit to create a type using TypeBuilder. There are couple of posting on this model.One such example is here. I approached this model to create a sample code which would generate a 1000 rows and 50 columns and it took almost 2.6 seconds.
- The second approach is using property bag model and using Silverlight’s suppport for indexer for binding. In this model, the same number of cell generation took only 1.4 seconds. So I decided to stick to this model. I am not going to explain, since Xavior’s blog explained it so good.
So lets look at the code which display our Person List in data grid.
We will add a new class called DynamicDataContext as per Xavior explained in his blog
Since the dynamic object does not support reflection, to show all the properties of the dynamic class in the grid, we need do couple of things in XAML and its code behind. First stop XAML
We need to make sure we are not auto generating the columns since Silverlight does not know which are the columns we are going to have in grid, we need to manually create it in the code behind and then add it to the grid. So to do that we will mark the auto generate columns to ‘False’.
Before we go into code behind and see how we create the columns, first look at the ViewModel and see the what are we doing there.
First stop we create the list of DynamicDataContext for People property which is bound to the grid as
Line 3-11 we create the People which is what bound to our grid in XAML.
When we generate the person collection, at the end, we publish an event for view to create the associated columns in the grid, by passing all available column names. It is done by publishing an event with list of column names at line 22. This event publishing is Jounce model of passing information between components.
Now lets look at the view code behind.
This is all Jounce here. When view model send the list of string, (don’t write production code like this 🙂 ) the view event sink intercepts and perform Handle Event method. For every element in the list, we create a new column and add it to our grid to display. That’s about it. Now if you would run this, you will get the result like the following
Very simple huh? I think Xaviour’s blog was exceptional in explaining the DynamicDataContent and how we use Silverlight 4’s indexer to identify and bind the dynamic columns.
I want to stop here with couple of points.
1. First of all, we need to create all the columns for the gird in the code behind. So once the collection is build you can send an event over to view and build it there. But most of the cases, you will first identify all the columns that are required to build the columns, so before you start building the data collection, you send the information over to View and build the grid columns before hand.
2. I am sure you have noticed the INotifyPropertyChanged interface implementation, that means we can track the data change events.
3. In ‘DynamicDataContext’, all we are tracking is bound object’s value change. We can extent this further to add your Entity Framework’s entity in it so that you can make changes to the underlying entity in the Data Context itself so that you can make use Entity Frame work’s change tracking for back end data update.
4. You can event extend the ‘DynamicDataContext’ to create hierarchical classes and generate tree like grid with ease. I will try to modify the ‘DynamicDataContext’ in the future blog to show this ability.