Jeff Handley

DomainDataSource, ComboBox, and Load Blocking

Jeff Handley — Tue, 22 Jun 2010 09:36:45 GMT

Over on our forums, many of you have reported difficulty with the ComboBox control when using RIA Services. Kyle McClellan (@KyleMcClellan) suggested that we drill into various ComboBox scenarios to see what works well and what doesn’t. Our goal was to produce some samples that address common scenarios, and to offer general guidance for ComboBox usage.

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>.

Should I Use DomainDataSource for a ComboBox?

Short answer: No

While I rejected the notion at first, as did the DomainDataSource’s PM, Deepesh Mohnani (@DeepeshM), we all came to the conclusion that the DomainDataSource control doesn’t do a very good job integrating with the ComboBox for the above scenarios. There are a few things getting in the way.

Async Data Loads

When you bind the ComboBox’s ItemsSource to a DomainDataSource and then invoke the load, the ComboBox doesn’t handle bindings to the SelectedItem or SelectedValue because the item/value doesn’t yet exist in the list. The selection is bound synchronously, but the items are loaded in asynchronously. This mismatch will cause you all sorts of frustration.

Load Blocking

The DomainDataSource halts its data loads once there are changes to the DomainContext. There is some background on this issue in this blog post, where I solicited feedback about mixing data loads with pending changes. We made the decision to block loads once changes exist, to prevent some nasty conflicts from occurring.

The load blocking becomes a problem with ComboBox because you are usually editing or adding an entity—as soon as you’ve started doing this, HasChanges becomes true, and subsequent loads for the DomainDataSource will be blocked. This problem is exacerbated when dealing with cascading drop-downs where you want to allow the user to drill down to make a selection.

Non-Entity Types

DomainDataSource has no support for loading lists scalar types—it’s limited to EntityQuery operations. So if you have an [Invoke] operation on the server that returns a collection of scalar values, there’s no way to use the DomainDataSource to load and expose this data.

But It Works For Me

We’ve seen (and written) many samples where DomainDataSource is used to successfully populate a ComboBox, but it really seems that once you grow beyond the simplest scenarios, it just breaks down. It’s probably not wise to use a solution that isn’t going to scale with your scenarios.

What Should I do?

Short answer: Subscribe to Kyle’s Blog

Kyle put together a blog post that includes a sample application, a ComboBoxDataSource control, and a ComboBox extension class that drastically simplifies many scenarios. Go read his post now.

As an aside, Kyle is taking over as the primary developer of the DomainDataSource feature for RIA Services. I have thoroughly enjoyed this feature, and I’ll still be involved, but Kyle is the new dev owner. Kyle did some heavy lifting in the feature area in V1 too, including the removal of ControlParameter and all of the support for ICommand and other Silverlight 4 niceties.

Will DomainDataSource Support ComboBox in the Future?

Short Answer: You tell us… should it?

Kyle and I spent some time talking through what we could do to improve the ComboBox support for DomainDataSource. There are a couple of ideas we wanted to put out there to get feedback.

Read-Only Mode for DomainDataSource

As I alluded to, we found many reasons why the DomainDataSource should not perform data loads when the DomainContext has changes. But we’re considering offering an IsReadOnly property on the control that would indicate that the data to be loaded is read-only data. When IsReadOnly is set to true, that would have the following effects on the control’s behavior:

Loads would not get blocked when the DomainContext.HasChanges property is true;
The DomainDataSource would not support Add or Remove actions against in read-only mode.

We think this read-only mode would help in the ComboBox scenarios because you can now have the ComboBox ItemsSource bound to a DomainDataSource that can load data after the user begins adding or editing entities. Cascading/drill-down selections would be possible because the loads would never be blocked. We’d still have the async loading problem to deal with though.

DataSource Control for non-Entity types

The DomainDataSource control is limited to calling EntityQuery load operations. Much of the functionality of DomainDataSource could be extracted out into another control that could work against any InvokeOperation though. Imagine having a method on the server that returns an IEnumerable<int> to return the list of years for car selection - there’s no reason to make an Entity out of Year just so that you can put a Query method on it for the DomainDataSource to be able to call it?

In fact, Kyle’s sample includes a ComboBoxDataSource control that handles both Query and Invoke operations. This is a very light-weight solution. Perhaps it’s enough.

What Say You?

Is this an area that we need to invest in? Would you like to see these scenarios addressed with the DomainDataSource, a separate DataSource, or in some other way? How do you think ComboBox should behave when ItemsSource is bound to an async collection? Does Kyle’s sample give you what you need?

Technorati Tags: RIAServices,DomainDataSource,ComboBox,Silverlight

Async Validation with RIA Services

Jeff Handley — Wed, 26 May 2010 20:06:08 GMT

Almost a year ago, I posted a lengthy article on how to implement Async Validation with RIA Services and DataForm. It was hard; much harder than it should have been, and we all knew it. Since then, things have changed, and async validation is a lot simpler. Let’s take a look at why it’s easier and how you can easily perform async validation in your application.

INotifyDataErrorInfo

Silverlight 4 shipped with an interface called INotifyDataErrorInfo, and controls that previously supported validation by way of exceptions now support async validation through this interface. This laid the groundwork for RIA Services to offer a simple mechanism for adding validation errors to entities at arbitrary times and having the controls show those validation errors just like all others.

INotifyDataErrorInfo includes an ErrorsChanged event that is used to notify controls that errors have changed for the object. After this event is raised, the control (for instance the TextBox) will call the GetErrors method to see what errors there are for the property or object that had its errors change. For entity-level errors, a null or empty property name is used.

Implementing this interface can actually be a bit of work. You need to maintain a list of errors for all properties as well as the entity itself, and as any changes to the errors are made, you need to raise the appropriate events. It’s not rocket science to implement the interface; it’s just a bit of plumbing, especially if you want to allow for errors to be changed in bulk and raise only the minimal number of events to cover the spectrum.

Entity.ValidationErrors

The RIA Services Entity class previously had a read-only list of its current validation errors. When we implemented INotifyDataErrorInfo, we took this a step further though, and we made the property an ICollection<ValidationResult>, allowing you to call Add, Remove, and Clear on the collection to manipulate the errors at any time, even outside of the standard DataAnnotations validation stack. If you want to roll your own validation engine, you can do so and simply pump ValidationResult instances into the ValidationErrors collection.

The best part of this collection is that it’s a custom collection class that I created that sends notifications back to the Entity when errors have changed overall, for a property, or at the entity level. This allows the entity to then easily raise condensed ErrorsChanged events using the INotifyDataErrorInfo interface. This means that when you call Add, Remove, or Clear on the ValidationErrors collection, we translate that into the necessary INotifyDataErrorInfo events so you don’t have to--simply modifying the collection will result in the UI showing the updated errors; it can’t get any simpler.

Async Validation Example

Validating the availability of a username is a canonical asynchronous validation scenario. We can implement this scenario by starting with a Silverlight Business Application solution. Create one of these projects from the Silverlight tab in the New Project wizard. Once you have the blank project, we can implement this async validation in only a few steps.

First, we need to create a DomainService method that can be called to determine if a username is available. We’ll do this in the UserRegistrationService.cs file that is created for you in the Services folder. Within the UserRegistrationService class, add the following method:

[Invoke]

public bool IsUsernameAvailable(string username)

    return !Membership.FindUsersByName(username).Cast<MembershipUser>().Any();

Second, we need to create a custom validator that can invoke this DomainService method on the server synchronously, or use the generated DomainContext from the client to make the call asynchronously. Create a new class file in the server project and call it UsernameValidator.shared.cs. By using the .shared.cs extension, the code will automatically be available to the Silverlight project as well as the server project. Here’s the code we need in the class; notice that some of the code runs on the server, and some runs from Silverlight, using #if directives.

    using System.ComponentModel.DataAnnotations;

    #if SILVERLIGHT

    using System.ServiceModel.DomainServices.Client;

    #endif

    namespace AsyncUsernameChecker.Web

    {

        public static class UsernameValidator

        {

            public static ValidationResult IsUsernameAvailable(string username,

              ValidationContext validationContext)

            {

                ValidationResult errorResult = new ValidationResult(

                  "Username already taken",

                  new string[] { validationContext.MemberName });

    #if !SILVERLIGHT

                UserRegistrationService service = new UserRegistrationService();

                if (!service.IsUsernameAvailable(username))

                {

                    return errorResult;

                }

    #else

                UserRegistrationContext context = new UserRegistrationContext();

                InvokeOperation<bool> availability = context.IsUsernameAvailable(username);

                availability.Completed += (s, e) =>

                {

                    if (!availability.HasError && !availability.Value)

                    {

                        Entity entity = (Entity)validationContext.ObjectInstance;

                        entity.ValidationErrors.Add(errorResult);

                    }

                };

    #endif

                return ValidationResult.Success;

            }

        }

    }

On the server, all validation must occur synchronously, and we do that by invoking the UserRegistrationService.IsUsernameAvailable method directly; if the username is not available, we return an error result, otherwise we return ValidationResult.Success.

On the client, this validation will need to be performed asynchronously. The approach I took here was to to return ValidationResult.Success from the validation after invoking a call to the UserRegistrationContext.IsUsernameAvailable method. When that invocation completes (asynchronously), we check the return value of the method (and also that no errors occurred). If the method returned false, then we add the error result to the entity’s ValidationErrors collection. As stated above, by simply adding a validation result to the error collection, the appropriate INotifyDataErrorInfo event will be raised, and the UI will be updated with the error message.

Third, and last, we need to apply a [CustomValidation] attribute to our property that needs to utilize this validation. Open up the Models\RegistrationData.cs file and find the UserName property; it already has a bunch of metadata applied to it. We need to add another attribute, such that the property is now represented as follows:

    /// <summary>

    /// Gets and sets the user name.

    /// </summary>

    [Key]

    [Required(ErrorMessageResourceName = "ValidationErrorRequiredField",

        ErrorMessageResourceType = typeof(ValidationErrorResources))]

    [Display(Order = 0, Name = "UserNameLabel",

        ResourceType = typeof(RegistrationDataResources))]

    [RegularExpression("^[a-zA-Z0-9_]*$",

        ErrorMessageResourceName = "ValidationErrorInvalidUserName",

        ErrorMessageResourceType = typeof(ValidationErrorResources))]

    [StringLength(255, MinimumLength = 4,

        ErrorMessageResourceName = "ValidationErrorBadUserNameLength",

        ErrorMessageResourceType = typeof(ValidationErrorResources))]

    [CustomValidation(typeof(UsernameValidator), "IsUsernameAvailable")]

    public string UserName { get; set; }

The line we added is [CustomValidation(typeof(UsernameValidator), “IsUsernameAvailable”)]. This indicates that the property uses a custom validation method defined on the UsernameValidator class, under the method name of IsUsernameAvailable. It’s the method we created above, and we made it available for both the server and the client.

We’re done. Three steps and we now have fully-functioning async validation. Run your app, register a user, log out, and then try to register the same username again and you’ll see the validation error pop up.

Validation Failures from the Server

I really favor the approach of immediately returning Success for async validation, and then only adding the error if the validation came back as a failure. This allows the end user to continue with other data entry but get informed if something they entered was found to be invalid. If the async validation cannot be processed for any reason, and the user submits the data to the server, the validation will be invoked again on the server and the error message will be returned all the way back to the client and the UI will display the error message. This is all possible because of how we process validation failures from the server.

When validation errors occur on the server, we serialize those messages and send them back to the client, aborting the data submission that was requested. When the client receives these error messages, new ValidationResult instances are created and added to the entity’s ValidationErrors collection. Because of INotifyDataErrorInfo support, this can happen asynchronously and the ErrorsChanged event will be raised, notifying the UI and displaying the error messages. In the end, the experience should be seamless for both the application developer and (more importantly) the end user. Ultimately, there should be no way to distinguish client-side validation errors from server-side validation errors--no matter which tier the validation errors occurred on, RIA Services does the work for you of informing the UI and getting the message displayed.

Limitations

There are some limitations to the async validation support that you should be aware of though; the limitations are really in the Silverlight SDK/Toolkit controls. With DataGrid or DataForm, you can only have a single entity in edit mode at any time; while that entity is being edited, the UI will respond to INotifyDataErrorInfo events and display error messages appropriately. But if the user has made changes to multiple entities, or has simply navigated away from an entity that later is determined to have an error, the controls won’t do anything to change currency or navigate back to an entity that has an error. This limitation really boils down to the fact that there’s no single way to address this problem for all applications--you need to handle this yourself, however you see fit for your application. When you call SubmitChanges for a DomainContext, be sure to handle its error condition and check for validation errors on entities, then make your application handle the conditions of errors on entities that aren’t currently active in the UI.

Emerging Patterns?

I’d love to hear about patterns that you see emerging in your code for how you are implementing asynchronous validation. If you tackle the above limitation in a clever way, do share. And if you find other good ways to write async validation methods, please share your approaches. We’d love to hear how we can further improve the experience for validation.

Also, Nikhil Kothari (the RIA Services architect) took a slightly different approach when he was implementing async validation. Instead of plugging it in with the validation attribute, we added explicit calls to a validation method from both his DomainService and his client (in the UI). He has a great post that goes pretty deep with several aspects of validation.

Technorati Tags: RIAServices,Silverlight,DataAnnotations,Validation

RIA Services V1.0 and Beyond

Jeff Handley — Mon, 24 May 2010 22:39:41 GMT

I came to Microsoft 2 years ago to join project Alexandria, which had the goal of making Silverlight an approachable framework for building business applications. The domain really excited me and it’s been an honor to work on this product. In case you’ve been living under a rock, we released the official 1.0 version of RIA Services back on May 17th. Here are some links to announcements that I’m sure you’ve already seen.

There were about 1000 other posts that I saw from folks too, which was exciting. The level of enthusiasm around our product is fantastic.

Beyond Version 1.0

Our team isn’t slowing down at all. In fact, if anything, we’re picking up the pace. We’re restructured the team and we’ve adopted the Scrum model; we started our 3rd 2-week iteration today in fact. I’m really proud that our team has been open in the past, and we’re turning that up a notch by asking the community to help us shape our subsequent releases.

After releasing version 1.0, we compiled our list of DCRs (Design Change Requests) that we had not completed for our first release, and we published the list on uservoice and asked everyone to vote for what they think is important. If you haven’t voted yet, please go to http://riaservices.mswish.net and cast your 10 votes. I was asked over Twitter which of the features on the list we’re seriously looking at; the answer was all of them. We’re truthfully using this list as an input factor into our prioritization (it’s not the only input factor of course though).

One of the items that is currently near the top of the list is using T4 for code generation. We were discussing this item in a meeting today and several of us wondered if that feature has enough “Pow Effect,” and I’d love to hear what you think about that. In fact, I went ahead and set up a quick poll here: http://twtpoll.com/bb5rvc - Tell us, does T4 support count as a “sizable feature?” In my mind, it does, because of the extensibility it would offer to the product. For instance, perhaps AJAX/jQuery support could be built on top of RIA Services using a custom T4 template; or maybe someone could create a UI scaffolding solution using T4 templates. I consider the long-term benefits of T4 support limitless, even if we don’t open up all of the possible scenarios with our first T4-compatible release.

If you’d like to influence the direction of RIA Services, I hope that you’ll reach out to us as much as we’re trying to reach out to you. Go to the uservoice site and vote for your features, but also leave comments about why the features are important to you and in what scenarios you’d use them. Watch for us to put out polls and other posts asking for feedback and suggestions too.

Technorati Tags: RIAServices

Member.Of – Avoiding hard-coded strings for property names

Jeff Handley — Sat, 10 Apr 2010 10:32:19 GMT

In the hallways of building 42, several of us have talked about how often we need to hard-code member names as strings in code, but we always feel like there should be some language operator to do this. We’ve specifically said there should be a memberof() in C# the same way there’s a typeof() operator.

I got tired of waiting for it though, and decided to see how closely I could come to creating this behavior. What sparked it was my usage of NHibernate’s Restrictions class tonight. I was looking at a post on Ayende’s blog showing examples of queries such as the following:

var blogs = s.CreateCriteria<Blog>()

    .Add(Restrictions.Disjunction()

             .Add(Restrictions.Eq("Title", "Ayende @ Rahien"))

             .Add(Restrictions.Eq("Subtitle", "Send me a patch for that")))

    .List<Blog>();

The hard-coded strings just make me sad; probably more so than they should, but I can’t help it. Here’s what I really want to see:

var blogs = s.CreateCriteria<Blog>()

    .Add(Restrictions.Disjunction()

             .Add(Restrictions.Eq(memberof(Blog.Title), "Ayende @ Rahien"))

             .Add(Restrictions.Eq(memberof(Blog.Subtitle), "Send me a patch for that")))

    .List<Blog>();

I obviously can’t add a memberof operator, and I also can’t make Blog.Title or Blog.Subtitle work. But this isn’t too far off:

Blog blog = null;

var blogs = s.CreateCriteria<Blog>()

    .Add(Restrictions.Disjunction()

             .Add(Restrictions.Eq(Member.Of(() => blog.Title), "Ayende @ Rahien"))

             .Add(Restrictions.Eq(Member.Of(() => blog.Subtitle), "Send me a patch for that")))

    .List<Blog>();

It’s a bit more verbose, but the member is now checked at compile time. Here’s a link to the unit tests that I have for my Member class: http://codepaste.net/t3oznt. And here’s the link to the current code for this Member class: http://codepaste.net/tfwmsu.

Here are my favorite tests:

[TestMethod]

public void CanGetMemberInfo()

    Patron patron = null;

    MemberInfo member = Member.Of(() => patron.FirstName);

    Assert.IsInstanceOfType(member, typeof(MemberInfo));

    Assert.AreEqual<string>("FirstName", member.Name);

[TestMethod]

public void CanGetMemberAsString()

    Patron patron = null;

    string member = Member.Of(() => patron.FirstName);

    Assert.AreEqual<string>("FirstName", member);

[TestMethod]

public void PropertyChangedEventArgsIsEasy()

    PropertyChangedEventArgs args = new PropertyChangedEventArgs(Member.Of(() => this.SomeProperty));

    Assert.AreEqual<string>("SomeProperty", args.PropertyName);

[TestMethod]

public void RaisePropertyChangedIsEasy()

    string propertyName = this.RaisePropertyChanged(Member.Of(() => this.SomeProperty));

    Assert.AreEqual<string>("SomeProperty", propertyName);

public string SomeProperty { get; set; }

private string RaisePropertyChanged(string propertyName)

    return propertyName;

Glenn and I had previously created a RaisePropertyChanged() method that accepted an Expression<Func<object>> to do this same thing basically, but I really like having Member.Of() as a general-purpose method that will implicitly convert to either a string or a MemberInfo, allowing me to use it anywhere that I need to specify a member name or info.

So now that I’m all excited about this, please burst my bubble and tell me why I shouldn’t do this. But if you like the idea of a memberof() being built into the language to do this, do speak up. Maybe we’ll convince Anders of it!

Technorati Tags: INotifyPropertyChanged,MemberOf,Linq

RIA Services - Documentation Guidance and Community Samples

Jeff Handley — Wed, 31 Mar 2010 02:20:54 GMT

As the RIA Services team is wrapping up our V1 release, several team members have been diving into the forums, writing blog posts, and in general trying to connect with the community to make sure we’re tying up all of our loose ends. We would also like to make sure that we have our documentation bases covered, but we’d like to solicit some candid feedback for this area in particular.

Documentation Approaches

What forms of documentation would you like to see us work on? Do you like quick-start tutorials, or do you prefer deep-dives? How would you prioritize these efforts? In your eyes, what’s the best way for us to explain the various features of the framework with you?

Karl Shifflett and I concluded that it would be great to have a 1-page quick reference guide to the RIA Services metadata attributes. This would show a quick illustration of when and how to use attributes like [Include], [Exclude], and [Association]. Do you agree that this would be useful? Are there other 1-page quick references that you can think of?

Sample Applications

We’re also interested to know if you have any RIA Services sample applications that you’d like to see added to our Code Gallery site or the silverlight.net community samples. We know that many of you (yes, I’m looking at you Fredrik and Colin) have been doing an amazing job of building up the RIA Services community… do you have sample applications you’d like to share?

Any Favorites?

What are your favorite links out there for learning RIA Services? Did you like Brad’s 26-part series, Deepesh’s guide to Configuring your DomainServices for Windows Phone 7, Nikhil’s RIA Services and Validation post, Colin Blair’s blog, Fredrik Normén’s blog, or anything else? Or do you simply jump onto MSDN and call it a day? Post your favorite links and we’ll make sure they get some link-love! And we’ll also look at those articles to see if we can get more similarly styled documentation created.

General Feedback

We’d also like to hear your general impression of how we’re doing with documentation. What are we doing that you love, and what do you hate? We are open to all forms of (constructive) feedback so please let us know how we can improve. We would really appreciate any guidance you have to offer!

Feel free just to leave comments here, and I’ll aggregate them and share them with the team.

Technorati Tags: RIAServices,Silverlight

DomainDataSource in a ViewModel

Jeff Handley — Mon, 22 Mar 2010 04:05:16 GMT

As I was writing up a response to the questions on a forums post about using DomainDataSource from a ViewModel, I thought I should just publish the notes here. I hope this helps people understand what will and will not work from the DomainDataSource when being used outside the visual tree.

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.

AutoLoad

In order for auto-load to work, the control must be loaded into the UI tree. Auto-loads are typically used when you have Filters, Sorts, and/or Query Parameters driven from UI controls. The DomainDataSource will wait for control to get the Loaded event, and then dispatch the first auto-load. Until that event occurs, all auto-loads are queued up. When outside the visual tree, this Loaded event will never be raised and no auto-loads will ever occur.

Just because auto-loads won’t occur doesn’t mean you can’t use the DomainDataSource from a ViewModel. Instead of relying on these automatic loads after changing property values, you can call the Load() method as needed. With the Release Candidate of WCF RIA Services, we have relaxed the Load method such that it won’t throw exceptions if a load is already pending. So if you call Load multiple times, we will cancel all but the last call. Note that it is possible that the control will submit the load request to the server from a canceled load (and just ignore the response), but it should now be easier to programmatically call the Load method from your ViewModel.

ElementName Bindings

As I illustrated recently, DomainDataSource’s Filter, Sort, Group, and Query parameters now all support element name bindings for driving the control’s inputs from the UI. These bindings won’t work when the control is not part of the visual tree or resources. But chances are, if you’re using the DomainDataSource from a ViewModel, you aren’t trying to bind its inputs to UI elements.

RIA Services vNext

I’d love to hear more about your scenarios where the DomainDataSource isn’t working well for you when you’d like it to. We’re working on our plans for the next version of RIA Services, so there’s no better time to share your feedback and suggestions!

Writing a Custom Filter or Parameter for DomainDataSource

Jeff Handley — Thu, 18 Mar 2010 23:14:15 GMT

This post comes to you from a guest writer, Kyle McClellan. Kyle works with me on the RIA Services team and he’s contributed to the DomainDataSource feature (among many other features in the framework). Kyle made the changes that allowed us to remove ControlParameter and use ElementName bindings for FilterDescriptor and Parameter that I recently blogged about.

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.

A common request is to pass the user’s name or other profile information through to a DomainService operation. Please keep in mind this is not a substitute for authentication or authorization, but can be effectively used to shape the data that is being returned. In the RC release, you can write it like this.

<dds:DomainDataSource x:Name="DDS" QueryName="GetEntitiesForUser">

    <dds:DomainDataSource.DomainContext>

        <appweb:SampleContext />

    </dds:DomainDataSource.DomainContext>

    <dds:DomainDataSource.QueryParameters>

        <dds:Parameter ParameterName="userName"

                       Value="{Binding User.Name, Source={StaticResource WebContext}}" />

    </dds:DomainDataSource.QueryParameters>

</dds:DomainDataSource>

However, you might find this gets tedious or want to encapsulate common functionality you use frequently. The solution in our RC release is to create your own derived filter or parameter type. A careful observer might notice we left the FilterDescriptor, GroupDescriptor, Parameter, and SortDescriptor unsealed for just this reason. This allows you to create a new CurrentUserParameter type and write the following.

<dds:DomainDataSource x:Name="DDS" QueryName="GetEntitiesForUser">

    <dds:DomainDataSource.DomainContext>

        <appweb:SampleContext />

    </dds:DomainDataSource.DomainContext>

    <dds:DomainDataSource.QueryParameters>

        <app:CurrentUserParameter ParameterName="userName"/>

    </dds:DomainDataSource.QueryParameters>

</dds:DomainDataSource>

In the constructor of the CurrentUserParameter, you can take care of binding and other initialization.

public class CurrentUserParameter : Parameter

    public CurrentUserParameter()

        Binding binding = new Binding("User.Name");

        binding.Source = WebContext.Current;

        BindingOperations.SetBinding(this, Parameter.ValueProperty, binding);

The solution can be applied equally well to filters, groups, parameters, and sorts. If you find yourself writing the same filter over and over or discover you need a little more than standard binding, it’s probably worth your while to create a derived filter.

If you’d like to see this capability in action, download this sample solution that demonstrates it. This solution requires the Visual Studio 2010 RC and RIA Services Release Candidate.

Technorati Tags: DomainDataSource,RIAServices,ControlParameter,FilterDescriptor,Kyle McClellan

DomainDataSource Filters and Parameters

Jeff Handley — Tue, 16 Mar 2010 02:24:10 GMT

Of all changes that made it into the RIA Services RC release, one of the ones that I'm happiest about is the deletion of a class called ControlParameter. 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!

Let’s take a look at the changes related to Filters and Parameters…

ControlParameter is gone… Good Riddance!

Since the inception of RIA Services, the DomainDataSource control has relied upon ControlParameter tags for specifying Filters and Query Parameters that are based on user input. Here’s a snippet of what you’d often see:

<riaControls:DomainDataSource Name="storeDomainDataSource" AutoLoad="True"

                              LoadedData="storeDomainDataSource_LoadedData"

                              QueryName="GetStoresQuery">

    <riaControls:DomainDataSource.DomainContext>

        <my:ContactContext />

    </riaControls:DomainDataSource.DomainContext>

    <riaControls:DomainDataSource.FilterDescriptors>

        <riaData:FilterDescriptorCollection LogicalOperator="Or">

            <riaControls:FilterDescriptor PropertyPath="StoreName"

                      Operator="Contains">

                <riaData:ControlParameter ControlName="storeFilter"

                                          PropertyName="Text"

                                          RefreshEventName="TextChanged" />

            </riaControls:FilterDescriptor>

            <riaControls:FilterDescriptor PropertyPath="City"

                      Operator="Contains">

                <riaData:ControlParameter ControlName="storeFilter"

                                          PropertyName="Text"

                                          RefreshEventName="TextChanged" />

            </riaControls:FilterDescriptor>

            <riaControls:FilterDescriptor PropertyPath="StateProvince"

                      Operator="Contains">

                <riaData:ControlParameter ControlName="storeFilter"

                                          PropertyName="Text"

                                          RefreshEventName="TextChanged" />

            </riaControls:FilterDescriptor>

        </riaData:FilterDescriptorCollection>

    </riaControls:DomainDataSource.FilterDescriptors>

</riaControls:DomainDataSource>

Here’s what the above code translates into with the Release Candidate approach:

<riaControls:DomainDataSource Name="storeDomainDataSource" AutoLoad="True"

                              LoadedData="storeDomainDataSource_LoadedData"

                              QueryName="GetStoresQuery" FilterOperator="Or">

    <riaControls:DomainDataSource.DomainContext>

        <my:ContactContext />

    </riaControls:DomainDataSource.DomainContext>

    <riaControls:DomainDataSource.FilterDescriptors>

        <riaControls:FilterDescriptor PropertyPath="StoreName"

                  Operator="Contains"

                  Value="{Binding ElementName=storeFilter, Path=Text}" />

        <riaControls:FilterDescriptor PropertyPath="City"

                  Operator="Contains"

                  Value="{Binding ElementName=storeFilter, Path=Text}" />

        <riaControls:FilterDescriptor PropertyPath="StateProvince"

                  Operator="Contains"

                  Value="{Binding ElementName=storeFilter, Path=Text}" />

    </riaControls:DomainDataSource.FilterDescriptors>

</riaControls:DomainDataSource>

Notice that Parameter and FilterDescriptor both allow for their Value properties to use a Binding. In fact, all properties on Parameter, FilterDescriptor, SortDescriptor, and GroupDescriptor now support bindings (we use DependencyProperty for all of them now).

FilterDescriptorCollection Changes

Before the Release Candidate (as you can see in the first code snippet above), you always had to create a new FilterDescriptorCollection for the FilterDescriptors; this was required because we had a LogicalOperator property on the collection that would determine how the filters were combined. With the Release Candidate, we’ve made the FilterDescriptors property on DomainDataSource a read-only property, and we give you a collection by default. This translates into a few noteworthy points:

Your XAML (or code) will no longer create the FilterDescriptorCollection to use as the DomainDataSource.FilterDescriptors property value - instead you just put your FilterDescriptor tags directly into the FilterDescriptors property
The LogicalOperator property has moved up to the DomainDataSource class itself, as a FilterOperator property
The DomainDataSource.FilterDescriptors property will never be null and you cannot set it

Before making this change, it was literally impossible to set the LogicalOperator on the collection through the Properties window in Visual Studio, because apparently, no other collection ever created in the framework had properties on it that would need to be edited. This was a good indication that the previous design was awkward.

Enum Support

DomainDataSource previously did not support Enum filters; now it does. Stay tuned to my blog for another post in the near future that goes over this topic.

IgnoredValue Changes

FilterDescriptor.IgnoredValue allows you to specify a value that would indicate that the filter should be completely ignored. For instance, if you default a filter control to “[Any Value]” you wouldn’t want that string to be used when composing a query; set the IgnoredValue to “[Any Value]” and we will skip right over this FilterDescriptor when composing the query.

Before the RC release, FilterDescriptor.IgnoredValue defaulted to an empty string; this made it especially difficult if you wanted an empty string to actually be used for a filter value. Additionally, when we compared the the FilterDescriptor.Value to the IgnoredValue, we could very often get type mismatches. This happened a lot with numeric values; we’d end up trying to compare a numeric Value to a string IgnoredValue, and even if they were the same, we’d find they were not equal. Both of these behaviors have been changed with the release candidate.

Now, your FilterDescriptor will never accidentally get ignored because of an IgnoredValue default. We default that property to a static value called FilterDescriptor.DefaultIgnoredValue; it’s just a new object(). So if you were previously relying on the default IgnoredValue of empty string, you will now need to specify IgnoredValue="" within your XAML.

If you were experiencing issues dealing with numeric filters and other filters where you were trying to specify an IgnvoredValue, your issues should now be resolved. For instance, if you had IgnoredValue="0" on a filter for a numeric property, you likely noticed that the filter wasn’t being ignored--it will now get correctly ignored.

Namespace Consolidation

You will notice that we’ve consolidated all of the DomainDataSource-related classes into the System.Windows.Controls namespace. You won’t have to register multiple namespaces for working with DomainDataSource anymore.

Closing Down v1

With this Release Candidate, we’re really closing down RIA Services Version 1. Hopefully you’re recognizing many of these changes as items that you had thought could be improved upon. And as always, please don’t hesitate to share your feedback with me or my team.

Technorati Tags: RIAServices,DomainDataSource,ControlParameter,Silverlight

ContosoSales Application for RIA Services RC

Jeff Handley — Mon, 15 Mar 2010 20:20:20 GMT

With the release of the RIA Services Release Candidate, it was time to refresh the ContosoSales application that was first shown in the PDC keynote. Let’s take a look at the changes made to move to the new release.

The steps below are based on having downloaded the styled ContosoSales application from PDC. If you want to cut to the chase and download the new version of the solution, you can grab it here for use with the RIA Services RC bits.

Changes to References

In trying to migrate the application, the first thing we notice is that the namespaces have changed (again, and for the last time).

With the PDC09 release, project had the following assemblies referenced for RIA Services:

Silverlight Project:
- System.Windows.Controls.Ria
- System.Windows.Ria
ASP.NET Project:
- System.Web.DomainServices
- System.Web.DomainServices.EntityFramework
- System.Web.Ria

With the Release Candidate (Mix10) release, we now have:

Silverlight Project:
- System.ServiceModel.DomainServices.Client
- System.ServiceModel.DomainServices.Client.Web
- System.Windows.Controls.DomainServices
- System.ServiceModel.Web.Extensions
  (this isn’t a RIA Services assembly, but we now need this reference)
ASP.NET Project:
- System.ServiceModel.DomainServices.EntityFramework
- System.ServiceModel.DomainServices.Hosting
- System.ServiceModel.DomainServices.Server

Consume the New References

The next change to address is the web.config file where assembly and namespace names were referenced.

Change:

     <system.web>

      <httpModules>

        <add name="DomainServiceModule"

             type="System.Web.Ria.Services.DomainServiceHttpModule, System.Web.Ria, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />

      </httpModules>

    </system.web>

    <system.webServer>

      <modules runAllManagedModulesForAllRequests="true">

        <add name="DomainServiceModule"

             preCondition="managedHandler"

             type="System.Web.Ria.Services.DomainServiceHttpModule, System.Web.Ria, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />

      </modules>

    </system.webServer>

To:

    <system.web>

      <httpModules>

        <add name="DomainServiceModule" type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

      </httpModules>

    </system.web>

    <system.webServer>

      <modules runAllManagedModulesForAllRequests="true">

        <add name="DomainServiceModule" preCondition="managedHandler"

             type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

      </modules>

    </system.webServer>

This changed “System.Web.Ria.Services.DomainServiceHttpModule, System.Web.Ria” to “System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting” in two places.

The next step is to change the namespaces referenced by the DomainService and metadata files. Open up ContactService.metadata.cs and work through the changes needed for that file.

Remove the using statement for System.Web.DomainServices
Add a using statement for System.ServiceModel.DomainServices.Server

Open up ContactService.cs and make the following changes:

Remove the using statement for System.Web.DomainServices.Providers
Remove the using statement for System.Web.Ria
Add a using statement for System.ServiceModel.DomainServices.Hosting
Add a using statement for System.ServiceModel.DomainServices.EntityFramework

We also need to change the UpdateContact code from:

public void UpdateContact(Contact currentContact)

    if ((currentContact.EntityState == EntityState.Detached))

        this.ObjectContext.AttachAsModified(currentContact, this.ChangeSet.GetOriginal(currentContact));

To:

public void UpdateContact(Contact currentContact)

  this.ObjectContext.Contacts.AttachAsModified(currentContact, this.ChangeSet.GetOriginal(currentContact));

Let’s flip over to the Silverlight project, open up the Views\Home.xaml file and make some changes there. Let’s start off changing the xmlns:riaControls from "clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Ria" to "clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.DomainServices"

Build and Run

With that, the ContosoSales application is running again, using the WCF RIA Services Release Candidate release. Let’s make one more change before we call it finished though.

DomainDataSource ICommand Support

You might recall that when Scott Hanselman was building this app onstage at PDC, he had to dive into the code-behind for the screen and wire up the Save button. Well, with DomainDataSource’s newly added support for ICommand, you can now bind the button to a command.

The first thing we want to do for this is to remove the code-behind code for the save button’s click handler. Delete the following code:

private void SaveButton_Click(object sender, RoutedEventArgs e)

    this.storeDomainDataSource.SubmitChanges();

And now in the XAML, change the save button from:

<Button Content="SAVE" Grid.Row="1" HorizontalAlignment="Left" VerticalAlignment="Top"

        Margin="182,0,0,0" Name="SaveButton" Width="114" Height="36" FontSize="18"

        Click="SaveButton_Click" />

To:

<Button Content="SAVE" Grid.Row="1" HorizontalAlignment="Left" VerticalAlignment="Top"

        Margin="182,0,0,0" Name="SaveButton" Width="114" Height="36" FontSize="18"

        Command="{Binding ElementName=storeDomainDataSource, Path=SubmitChangesCommand}" />

Using the WCF RIA Services Release Candidate

Hopefully this post helps you get your own applications up and running with the release candidate. Here are some links to help you really get going with the new release:

RIA Services “Home Page” with download links – http://silverlight.net/riaservices
RC Breaking Changes Document
The updated version of this ContosoSales application
(with a couple of extra features for you to discover)

Technorati Tags: RIAServices,Silverlight

Lookups in DataGrid and DataForm with RIA Services

Jeff Handley — Sat, 13 Mar 2010 01:38:39 GMT

While off reading random blog posts on the tubes, I stumbled upon a post that describes a 101-level scenario of using lookup data in the DataGrid and DataForm with RIA Services. The author was struggling to find a solution for the problem and was clearly frustrated.

The scenario is very common; let’s use the Cars example where every Model refers to its Make.

We want a DataGrid that includes the make name as a column:

And we want a DataForm with a ComboBox for the Make:

Let’s tackle this in two steps: first we’ll make the DataGrid show the Make Name and second we’ll make the DataForm show the ComboBox of Makes.

In the metadata class for the Model, annotate the properties as such:

[Display(Order = 20, Name = "Base Price")]

public Nullable<decimal> BasePrice { get; set; }

[Display(AutoGenerateField = false)]

public int Id { get; set; }

[Include]

[Display(Order = 0)]

public Make Make { get; set; }

[Display(AutoGenerateField = false)]

public int MakeId { get; set; }

[Display(Order = 10)]

public string Name { get; set; }

This will lead to auto-generated fields in this order:

Make
Name
Base Price

The only problem this leaves for DataGrid is that we don’t want to display the Make, but instead, we want to display the Make.Name. One solution for this would be to override the ToString() method on Make and have it return the Name. But let’s handle this in the UI; here’s our XAML:

<riaControls:DomainDataSource AutoLoad="True"

                              Name="modelDomainDataSource"

                              QueryName="GetModelsQuery">

    <riaControls:DomainDataSource.DomainContext>

        <my:CarContext />

    </riaControls:DomainDataSource.DomainContext>

</riaControls:DomainDataSource>

<sdk:DataGrid AutoGenerateColumns="True"

              Height="200"

              ItemsSource="{Binding ElementName=modelDomainDataSource, Path=Data}"

              Width="400"

              AutoGeneratingColumn="DataGrid_AutoGeneratingColumn">

    <sdk:DataGrid.Columns>

        <sdk:DataGridTextColumn x:Name="makeNameColumn"

                                Binding="{Binding Path=Make.Name, Mode=OneWay}"

                                Header="Make Name" IsReadOnly="True" />

    </sdk:DataGrid.Columns>

</sdk:DataGrid>

Our DomainDataSource is loading our Models and the DataGrid is bound to the results. We are auto-generating the columns for the grid, but we’re also doing two extra things:

Handling the AutoGeneratingColumn event
Adding a read-only column to display the Make.Name

The code for the AutoGeneratingColumn event handler will prevent the auto-generation of the Make column, since we’re replacing it with a Make Name column:

void DataGrid_AutoGeneratingColumn(object sender, DataGridAutoGeneratingColumnEventArgs e)

    if (e.PropertyName == "Make")

        e.Cancel = true;

In order to get the DataForm to display the ComboBox, we need to customize the Make column’s auto-generation for that control too. Here’s the XAML for the DataForm:

<tk:DataForm ItemsSource="{Binding Path=Data, ElementName=modelDomainDataSource}"

             Name="modelDataForm"

             AutoCommit="False"

             AutoEdit="False"

             AutoGeneratingField="modelDataForm_AutoGeneratingField" />

And our handler for AutoGeneratingField will create a ComboBox for the editing:

void modelDataForm_AutoGeneratingField(object sender, DataFormAutoGeneratingFieldEventArgs e)

    if (e.PropertyName == "Make")

        ComboBox makes = new ComboBox { DisplayMemberPath = "Name" };

        Binding itemsSource = new Binding("Makes") { Source = this.modelDomainDataSource.DomainContext };

        Binding selectedItem = new Binding("Make") { Mode = BindingMode.TwoWay };

        makes.SetBinding(ComboBox.ItemsSourceProperty, itemsSource);

        makes.SetBinding(ComboBox.SelectedItemProperty, selectedItem);

        DataField makesField = new DataField

            Content = makes,

            Label = e.Field.Label

};

        e.Field = makesField;

The ComboBox has two bindings: ItemsSource is bound to the “Makes” property on the DomainContext, and SelectedItem is two-way bound to the “Make” property on the model.

There’s only one thing left missing from this solution—we need to load all of the Makes into the DomainContext. We can do this easily from within the page’s constructor:

public Home()

    InitializeComponent();

    CarContext context = (CarContext)this.modelDomainDataSource.DomainContext;

    context.Load(context.GetMakesQuery());

When adding a new model, we can see the Make field shows us the fully-populated list.

I would expect this pattern to be followed pretty regularly when dealing with lookup data. There might be some ways in your applications to condense this effort so that it can be reused across screens and types of lookup data.

Technorati Tags: RIAServices,DataForm,DataGrid,Lookup Data