D'Arcy from Winnipeg
Solution Architecture, Business & Entrepreneurship, Microsoft, and Adoption

Silverlight Binding and Events – Stop Thinking Like a Web Developer

Tuesday, December 30, 2008 3:03 PM

In my last post we started looking at a carousel control for Silverlight, and the changes that were required to bring it up from Silverlight 2 Beta 1 to Beta 2 and finally to the RTM.

I wanted to dive into the code further today to do some cleanup, get a better understanding of what’s actually going on, and do some playing around.

The first think you’ll notice about the code is that I’ve moved things around in the actual carousel panel control class. I put in regions (some people don’t like regions, I do) and got rid of the underscores in front of some of the local variables. Little clean up.

But I also was thinking “Hmm…this whole harness thing…is it really necessary?” So I added another xaml file, identical to the original one, but setting the panel properties through the control event handlers instead of through the binding mechanism.

My code went from this…


To this…


So the first drawback of using the events here instead of relying on binding to the object is obviously a lack of code reuse. I’d like to leave my carousel control totally agnostic from what is altering its values of height, width, speed, etc. So if I had three situations where I wanted to use the panel, but also provide some form of controls for altering its appearance or functionality, I have to create a tonne of control event handlers in my xaml code behind. Not very elegant.

Furthermore, look at the code…notice that each method checks to see if the panel is null first?I don’t know what the (for lack of a better word) page lifecycle is for a xaml file, but when this executes it hits all these control events…but the panel is still listed as null even though InitializeComponent has been called. In the harness class we still had to check for null in one spot, but at least it was just *one* spot and its encapsulated within the class.

We also lose the benefit of two way data binding that the harness version provides (that isn’t a feature of the harness class, but of the databinding mechanism in Silverlight). With the harness version of the code, if I add a button and set the harness object’s width property, the control bound to the object’s property will reflect the change. With the event handler method we lose that and would have to manually set any control’s value manually.

The other bit that seems a mystery to me as of now is how the carousel control automagically reacts to events fired from the harness object when a value is changed. There’s a pretty close link between the data context object and the consumer of that object and how one can pass notifications to the other.

Which brings me to the point of this whole post: While many win-form devs are reading this going “well DUH”, for us web developers this can be something totally alien. In the ASP.NET world, we’re used to having events for our controls and databinding seems to be looked down on or whispered in hushed tones. But doing development in Silverlight as if it was ASP.NET will bring nothing but pain and frustration. Web Devs need to embrace the differences and not try to force our old habits on this new platform.

Anyway, enough soap-box talk. Below is a link to the updated source that has both versions of the xaml (using a harness and without) and the code cleanup I did to the class. More posts on this to come!


No comments posted yet.

Post a comment