Thursday, March 18, 2010

Writing a Custom Filter or Parameter for DomainDataSource

by Jeff Handley via Jeff Handley on 3/18/2010 11:14:15 PM

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.