Wednesday, 16 April 2008

Silverlight 2: We're not quite there yet.

I've just spent two days in a lab in Reading on the Microsoft Campus. The lab topic was Silverlight, the up and coming UI technology that's set to seriously rival Flex and Flash.

The majority of the time was spent in breakout meetings discussing the pros and cons of the technology, and a lot of compare and contrast was done with Silverlight's main competitor, Adobe’s Flex.

Quite a few of the developers present had used Flex before or are currently in the process of evaluating Flex against Silverlight for future projects. Everyone seemed to agree that Silverlight has the potential to be a much better framework for Rich Internet Application development than Flex, and there were two main reasons for this.

Firstly, Flex was born out of a design application and therefore was not intended for real "line of business" application development. Second, Flex APIs are inconsistent (“quirky” was a word used frequently), thus requiring a lot more effort to train people to use the framework properly.

Silverlight is a much more intuitive technology for .NET developers. I could see this straight away as the programming model, the event wiring and handling etc., is just like in any other .NET application. Those at the seminar that had worked with both Silverlight and Flex said that proficiency in Silverlight (for a .NET developer) is gained in less than half the time of Flex. Also, the integration with other .NET technologies (services etc) makes it an appealing alternative. It fits right in there with the rest of the .NET family.

But, there are some big shortcomings. The Silverlight 2 control library isn’t complete, not by any stretch of the imagination. I was surprised to find that certain controls such as the DropdownList, TreeView, and DataGrid do not exist. And MS will not promise the inclusion of anything that's currently missing in any of the upcoming beta and CTP releases. Unfortunately MS feels burned by their openness around the Vista release and now hold their cards close to their chest. They'll listen to the community's feedback, but they will not promise delivery of anything just in case they cannot meet their own deadlines.

Despite certain controls not being available, Silverlight remains a really powerful technology. Indeed, it is so easy to use that you can knock up "anything" in very little time. I built a semi-reusable DropdownList control in less than half an hour (using a combination of a textbox, a button, and a listbox control). The beauty of Silverlight and XAML (its markup language), though, is that I could build this control entirely from scratch by drawing it using the Expression Blend application and vector graphics. That’s just too cool.

So Silverlight is powerful, and it makes a lot of previously laborious tasks simple. But nobody has yet used it on a truly big scale, and nobody seems to know or have any ideas on how it should be used for enterprise scale applications. Over the two days we saw a lot of seemingly large applications demonstrated, but I was left with the distinct feeling that the applications were heavy on the UI and thin on business logic. In other words, I wasn't convinced that they demonstrated how Silverlight is a good fit for the large type of applications that we need to build.

Also, we (several of us asked the same questions) were not able to get guidance on how large Silverlight applications should be structured from a development point of view. How do we build something like our current tools applications and share look and feel, navigation etc? How does the project structure look? How does deployment work? Nobody had any answers for this, because Silverlight is still in its infancy.

So, for those companies out there that wish to make Silverlight central to their software solutions there is a lot of pioneering work left to be done. It means blood, sweat, and tears. The technology isn't ready yet, so it's up to the community to make up for its shortcomings. But I think Silverlight will find its feet pretty soon.

Wednesday, 2 April 2008

DataBinding woes

I tore my hair out over this one, for hours. And the solution to the problem was so simple I felt stupid not to realise what was going on.

I have a custom server control called CustomerSummary. It has a single public Customer property that can be set declaratively on any page where it is used. I use this control in three different web applications, and implementing it in the first two was no problem. But when it came to the third application, the control never rendered. I just could not figure it out.

While debugging the control I realised that the Customer property was never set, even though it was correctly declared on the page with Customer=’<%# CurrentCustomer %>’ (CurrentCustomer is a property on the containing page’s code-behind). What the?

After much poking around and debugging a colleague looked at it and said: “Do you call DataBind() on your page?”. No, I don’t. And that’s why. The <%# %> expression is a databinding expression, so since the page didn’t call DataBind(), the CustomerSummary control was never bound to the customer data, and therefore never displayed.

So the first solution was to call DataBind() in the Page_Load method (this is what the first two applications do; that’s why it worked there). However, the same colleague that pointed out that DataBind() was missing pointed me to this article which explains custom code expression builders and how you can use them to avoid having to call DataBind() and bloating the ViewState. Sweet! It’s recommended reading.