Home >
One of the key features of Silverlight is how its binding mechanisms work. Silverlight borrows the concepts of XAML from WPF (Window Presentation Foundation). This post gives a overview of the binding features, after which I will follow up with some examples of how to take advantage of them.
So first, a little 20,000 foot view of XAML with WPF ... WPF can make for some very compelling user experiences through its powerful XAML based language. The XAML which is simply XML can be hand written or it can be written indirectly using through using a tool like Microsoft's Expression Blend software. Expression Blend makes it easy to drag and drop elements and visually design the layout for a UI ... all the while putting together XAML.
Silverlight also uses XAML to allow the rendering of its UI's. This means you can also use Blend to create Silverlight UI's, too. Other than visual eye candy, one of the key ingredients of XAML that makes it great for business applications is its simple and effective data binding mechanisms. Silverlight and WPF have very slightly different flavors of XAML based bindings, but they both are very effective. XAML based binding uses the concept of a DataContext to allow a UI Element to be bound to data object. Every UI Element can have a DataContext. However, if an element does not have a DataContext assigned to it, the UI Element will look to its parent UI Element to see if he has a DataContext assigned to it. This process continues as it bubbles up the chain of UI Elements. This allows for a data object to be assigned at a high level, perhaps the entire page, and all UI Elements have access to that DataContext.
Another option available is to have multiple DataContext's set in a page, for different UI Elements. This is a common choice when there is a parent child association in the page. For example, the Customer object is assigned to be the DataContext for a DataGrid showing a list of customers in the UI. However, when a Customer is selected, the individual customer object is assigned to be the DataContext for a set of UI Elements lower on the page. This hierarchical searching for a DataContext makes it easy to bind values with very little coding effort.
XAML binding also provides for binding modes, which dictate if the values are read only or read write. You can also specify whether or not the UI will "listen" for changes to the data or not. Another great feature is that values can be converted automatically using a converter class. The converter can take a vale in a database like a number representing a color and translate that to the actual color in the UI. So the database might store a 1 for yellow and the converter could take that value of 1, change it to a yellow Brush and fill a circle with that color in the UI.
This is just a glimpse at some of the things that can be done with XAML. I'll post some details and code samples of Silverlight data binding in my next post.
Tag Cloud
Podcasts & Screencasts
@InsideRIA on Twitter
Follow InsideRIA on Twitter
Facebook Application Development
Similar comments apply to MXML for Flex. An important benefit, in my mind, of MXML is that it's simply an alternate syntax for ActionScript: There is nothing you can do in MXML that does not have an equivalent series of ActionScript statements. This is what allows Adobe to even consider upcoming applications such as Flash Catalyst which rely on smooth movement into/out-of development mode.
Unless XAML shares this property (and I'd be surprised if it does given Microsoft's design/framework history), Silverlight is hugely disadvantaged relative to Flex for creating maintainable UIs.
XAML does share this property and there is nothing you can do in XAML that you can't do in C#--though the reverse isn't true as some operations really can only be done with C#. Having worked extensively with both XAML and MXML now, I will say that MXML is tremendously more intuitive and more flexible in the ways it allows the developer to duck in and out of code with such things as inline script tags and the ability to place expressions inline with the XML. XAML on the other hand feels much more verbose and overdone while at the same time being more restrictive. That said, the under the hood mechanisms beneath the XAML layer are much more powerful than what Actionscript and the Flash Player (or AIR for that matter) are capable of.
XAML will continue to grow, but in my opinion, Microsoft has a long way to go before it will make headway on the Flash/Flex market-share within the RIA community.
I agree with James. The architecture of XAML is far more better as compared to MXML. I would like to see less code for binding in XAML in future, plus XAML has the advantage of .net Framework and Visual Studio. But Flex has the benefit of being opensource and community driven as well as flash player's installation base. It would be interesting to see how both of these would shape up in the future.
at http://www.xamltemplates.net you can find styles for all the WPF controls i don't know if flash has something like this.