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.
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.
In the constructor of the CurrentUserParameter, you can take care of binding and other initialization.
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.