There have been a lot of opinions flying around the web-o-net about the problems with the control templating model in Silverlight 2.0.  I’m going to go out on a limb here, though, and say…I like it.  That’s right, I like the new model.  In fact (insert teeth gritting here), I wish we had done the same thing in WPF (gasp!).

The reasonable opinion against the new model (as I understand it) is based on the fact that Silverlight doesn’t have support for triggers in control templates (or just about anywhere for that matter).  This means more code and less XAML for defining those behaviors. 

In WPF, for example, if you wanted a control to respond to a mouse hover (and, say, change its color), you would create a trigger on the IsMouseOver property and then party in that trigger and create whatever storyboards (or setters) you want to implement that color change.  This all happens in markup. 

In Silverlight, on the other hand, the developer has to create an event handler for the MouseEnter and MouseLeave events and then explicitly load a set of storyboards with well known names to handle the transitions between those states.  Silverlight is doing a lot less heavy lifting for you and there’s definitely a code component to what, in WPF, seemed like a simple XAML task.

See how much better Silverlight is?  Okay, so the "better" part may not be obvious.  Here’s my take though:

First, things got much cleaner in the new component model.  Do you remember this doc?  It’s an attempt to prioritize the eight (that’s right, eight) different "best practices" for expressing control state changes and behavior in your control.  This includes: bindings, triggers, commands, named parts, etc.  This is some serious complexity and leads to some serious lack of discoverability.  This is why we needed projects like SimpleStyles.  Templating for WPF controls is simply not predictable (let alone toolable, but we’ll get to that) so we end up needing a lot of sample code to get people off the ground. Plus, it’s really tough for developers.  You have a myriad (well, eight) different recommendations for doing the same thing and the choice between them is not always clear even to an experienced WPF developer.

That said, you may have thought that the complexity was worth it.  It may seem, after all, like this complex model puts flexibility in the designer’s hand since, of those eight, two (bindings and triggers) have a very strong markup component to them.  Moreover, the Silverlight way (the named parts approach) looks a strong code component to it. 

The thing that is easy to forget, though, is the fact that all of those bindable and triggerable properties and events had to be defined by a developer at one point.  The IsMouseOver property had to be created somewhere.  So at the end of the day, it’s not that behaviors require more code now, it’s just a different kind of code: more event handlers and fewer property change handlers to kick off behaviors.

Second, the Silverlight model has a very good chance of being much easier to use in a tool like Blend.  Frankly, I haven’t seen a lot of people have great success with control templating in Blend.  Button and Checkboxes don’t count.  Try creating a template for a ComboBox or a Menu.  It’s really hard, even if you know what you’re doing.  Once again, this comes down to the complexity of the contract between the template and code. 

Imagine, on the other hand, a model where you can simply walk through a checklist and provide elements for each of the UI "parts" of the template and storyboards for each of the "behaviors."  Menu might have a lot of parts and behaviors, but at least there is a predicable way to discover and provide them.  In this kind of a model, the designer could theoretically retain much (if not all) of the flexibility he has in WPF but have a much easier time accessing it.

Silverlight 2.0 isn’t there yet, but the model they’ve chosen is at least predictable and declarable and that gets us much closer to the templating Xanadu that I just described.  Even in the meantime, we still have a model that’s much easier to understand and even code for and the only trade off is that now I the developer exposes behaviors by responding to events instead of responding to property changes.

Now having said all that, I would love to have triggers in control templates, styles and especially data templates in Silverlight.  In fact, not having triggers in data templates has resulted in some serious hackery on my part (in which I end up creating a UserControl everytime we have a data template with any complexity).  But I like where this new templating model is going and I hope it goes even further.