Introduction

In my last article, I introduced an extremely interesting new control coming out with Silverlight 3—the DataForm control. The DataForm control is general-purpose UI generator that reads the public properties of any bound object, or collection of objects, and produces a nice form. The content of the article was based on Beta 1 of Silverlight 3 that Microsoft released back at MIX09 last March.

As you may know, in mid July Microsoft announced the availability of the RTM of Silverlight 3. To my surprise, the DataForm control is no longer there. The DataForm control is still around and didn’t disappear entirely. For some reason, the control has been moved to the Silverlight 3 Toolkit and has undergone some facelift in its programming interface.

All in all, I still truly believe in the DataForm control and consider it a very powerful component with a brilliant future ahead. Maybe just because of this, the team reckoned that it probably deserved a more thoughtful review and needed to be driven in its development by some strong community feedback. The DataForm control is a rich user interface component that you basically take as is. Sure, you can customize it to a large extent, but you can’t change its internal architecture and API. More, the DataForm control falls in an area of development where you need a common approach on a variety of platforms—Silverlight, ASP.NET, WPF, maybe Windows Forms not to mention the relationship that all of this may have with Entity Framework.

In the end, the DataForm control in Silverlight 3 Beta 1 was probably a bit ahead of its natural time. And, in this regard and perspective, I personally agree with the decision of pushing it back to Toolkit mode. In addition, if you look at the details of the Silverlight 3 Toolkit, you see that the DataForm is not even considered among the most stable and mature components—which fact, in my opinion, just reinforces the points I made earlier.

This said, I can’t ignore that, in a way or another, Microsoft just released also the Silverlight 3 Toolkit. And in this toolkit, there’s an interesting control named the DataForm. With all possible caution that a still-in-the-works component requires, I think that if you find interesting my previous article based on Beta 1, you might be interested also in this update that focuses on the stage of DataForm at the time of Silverlight 3 RTM.

Getting the Silverlight 3 Toolkit

The Silverlight Toolkit is a collection of controls that extend the Silverlight toolbox but are not released necessarily within, and at the same time as, normal releases. The Toolkit is made of controls designed to fulfill precise user feedback and needs and comes with source code and unit tests. At this time, more than 20 new controls form the Silverlight 3 Toolkit.

Once you install the toolkit, your Visual Studio 2008 environment looks like in Figure 1.

Figure 1: The toolbox of a Silverlight application once the Toolkit 3 is installed.

Note also that the Visual Studio 2008 tools for Silverlight 3 don’t include a visual editor for the XAML markup. It has been replaced by a document outliner that just offers a tree-based view of the controls in the markup. The team though reassured that the visual editor will come back in the Silverlight Tools for Visual Studio 2010 and it will be much more usable and enjoyable. So it seems we won’t be missing it that much and that we will be rewarded significantly for this wait. Smile.

The DataForm At a Glance

Once bound to an object, or a collection of objects, the DataForm control produces a list of input controls to let developers view and edit any content. For example, if you use the following class Person the DataForm will use text boxes for string properties, check boxes for Booleans, and a date picker control for dates.

In addition, the DataForm can switch between view and edit mode and supports binding to a collection of objects. In this case, it also provides navigation capabilities looking like the Silverlight’s counterpart of the popular Microsoft Access data navigator component. Figure 2 shows the standard interface of the control in Silverlight 3 RTM. Styles can be applied to make it look just the way you want.

Figure 2: The DataForm control in action in Silverlight 3 RTM

Here’s the code you get once you have dropped a DataForm in a Silverlight page.

In Silverlight 3 RTM, more than in the Beta you find a number of public properties to pay attention to. Table 1 lists the most significant of them all.

Table 1: Some of the properties of the DataForm control.

Binding to Data

As mentioned, the user interface of the DataForm control entirely depends on the bound object. Two properties are defined for binding purposes: CurrentItem if you’re binding a single object and ItemsSource if you’re binding a collection of objects and want the DataForm to navigate through them. Data binding can occur both programmatically and declaratively in the markup. Here’s how to set ItemsSource declaratively.

In the code-behind class, or even declaratively, you set the DataContext property to the actual collection.

The toolbar with navigation buttons don’t display if only one object is bound. Alternatively, you can set the ItemsSource or CurrentItem properties directly without declarative binding.

The DataForm control may work in three different modes: ReadOnly, Edit, and AddNew. You can read the current mode via the Mode property. The Mode property, though, is read-only meaning that you switch from mode to another using methods or through a user-initiated action. Methods are listed in Table 2.

Table 2: Methods of the DataForm control.

The DataForm control only provides a tailor-made user interface for the user to edit a bound object. Any CRUD operation it performs is limited to the bound object instance or collection. In no way does it contain or link to any logic to load or save back to the original data source.

When the user commits changes the state of the DataForm changes to notify any interested surrounding code that the state of the bound object is updated. Boolean property IsItemChanged indicates whether pending changes exists in the bound object. However, the pending object doesn’t track original values and original values can’t be restored.

The DataForm manages automatically the disabled style of Commit and Cancel buttons when the control turns into Edit mode. The style of other buttons in the toolbar is also managed automatically. However, as a developer you can decide which buttons to show in the toolbar. The property behind the behavior is CommandButtonsVisibility. It takes values from the DataFormCommandButtonsVisibility enumerated type. (See Figure 3.)

Figure 3: The DataFormCommandButtonsVisibility enumeration

To display multiple buttons, you combine together multiple values using the logical Or. Declaratively, you assign a comma-separated string of values.

DataForm Events

The lifecycle of the DataForm control is characterized by a few events that signal important stages. Table 3 lists all supported events.

Table 3: Events of the DataForm control.

Because the DataForm is not linked to any logic that persists changes back to data store (i.e., a database), it is of particular importance the pair of events that signal when the control enters in, and exits from, in Edit mode. Here’s a typical implementation of the EditEnded event:

The event data structure simply lets you know about the reason that caused the exit from Edit mode. It can be Commit or Cancel depending on the clicked button or the value of the AutoCommit property. If the user commits, you might want to check whether changes have occurred and then proceed with any storage logic you may have around. To retrieve modified values, you use the CurrentItem property.

Summary

In Beta 1, the DataForm control was more static and less configurable than today in the Toolkit. Just for this reason, it is today not as stable as other controls in the Toolkit. As you may know, controls in the Toolkit are divided in three groups. There are those mature for full release and close to a possible inclusion in a Silverlight release; there are those stable enough; and there are those offered as a sneak preview of a possible future functionality. The DataForm currently belongs to the third group.

Is the DataForm usable today?

Because the control is in an early stage of development, a lot of water is expected to have to flow under the bridge. So if the control works for you today, use it but don’t found significant portions of your development on it. Not because it may not serve you today as you wish, but because it may change even significantly in a future release. And for a Toolkit frequent releases may be in order.

This said, I still believe that the DataForm—or a control like that—is a central piece of any GUI platform. The future will likely have such a control available.

About Dino Esposito

Dino Esposito is one of the world's authorities on Web technology and software architecture. Dino published an array of books, most of which are considered state-of-the-art in their respective areas. His most recent books are “Microsoft ® .NET: Architecting Applications for the Enterprise” and “... This author has published 53 articles on DotNetSlackers. View other articles or the complete profile here.

---

Discussion

Subject	Author	Date
Thanks for the clearing things up	Vince Plaza	10/16/2009 8:09 PM
I was a bit confused by the Silverlight.Net video on the subject, which was still referring to the Beta 1 functionality. This cleared up the changes. It would be great on a future article to demonstrate the use of bound combo or list boxes in the edit and new record templates. Thanks again. Reply | Permanent link
Corrected: Thanks for clearing things up	Vince Plaza	10/16/2009 8:13 PM
I corrected the excellent grammar in the subject.  :) Reply | Permanent link

---

Please login to rate or to leave a comment.