Search

Here are a few scenarios we looked at:

• Async loading of ItemsSource with a SelectedItem/SelectedValue binding;
• Cascading drop-downs such as selecting Year - Make - Model for a car;
• Binding a ComboBox to a list of non-Entity types, such as an IEnumerable<string>.

I’ve seen a few good posts out there using the DomainDataSource with a ComboBox that make things look easy. Since those were already well trodden paths I thought it would be important to identify some of the harder scenarios. After a bit of investigation, three things came forward as being particularly difficult.

• Loading ComboBox contents asynchronously
• Implementing cascading ComboBoxes
• Using ComboBoxes for Entity associations

I've heard many times that people are using the DomainDataSource in ViewModel scenarios.  Contrary to popular belief, this can work very well with the control as it is today; there are only a couple features that won't work outside the visual tree.  Aside from these two items, everything the DomainDataSource does is supported in a ViewModel.

Now that the ControlParameter has been properly disposed of, you might have noticed that Parameter has changed substantially. Before, a Parameter was used for filtering, grouping, sorting, and querying. Now it is only used in the last case. If you had previously defined your own parameter types, you might be wondering how to leverage them in the RIA Services RC release.

 Yes, ControlParameter is gone, gone, gone--finally!  If you’re wondering how you’ll get your UI-based filters and parameters to work without ControlParameter, do not fret… it’s easy; just use an ElementName binding!

The DomainContext class allows the Silverlight client to access the Domain Service Class you created on the server side. A new DomainContext class is automatically generated on the client side for you when you create a new Domain Service.

The biggest problem was when errors occurred during Load() or SubmitChanges(), server-side errors would be silently swallowed unless you opted into the LoadError, LoadedData, and SubmittedChanges events, and explicitly checked for errors.  With the PDC release, we've change this behavior, among others related to error handling.

During the PDC release milestone of RIA Services, we discovered an error from DomainDataSource when using AutoLoad="True" and when using a DataPager bound to the DomainDataSource’s Data property.  We found that when the PageSize property is specified on the DataPager and not on the the DomainDataSource itself, an exception would often (but not always) be thrown from DomainDataSource, indicating that a load could not be invoked while another load was in progress.  The reason for this will actually interest you most if you use AutoLoad set to False.

Awhile back, I asked for input on the DataView property and what API you would like to have for it.  We were designing a new class that would be created expressly for the purpose of the DomainDataSource.DataView property.  We wanted the API to do two thing for you: 1) Give you easy access to the properties and methods you will frequently use on the collection; and 2) Hide the properties and methods that are required to be implemented for interfaces but that you would not need to access programmatically often.  The result of this effort was a class named DomainDataSourceView.  You will see this with the PDC release of RIA Services.