Change the DataServiceContext of a RadDataServiceDataSource?

[Wayne]

The Data Service sample works fine when you instantiate a concrete service context object directly in the XAML of the RadDataServiceDataSource.

Should it be possible to data bind to the DataServiceContext property of a RadDataServiceDataSource instead?

I have an app that allows the choice of several OData services. When a service is chosen, I dynamically generate a service client proxy, and activate a new instance of that proxy's exported DataServiceContext-derived class. Now I want to bind that to my RadDataServiceDataSource (and of course change the binding to a completely different context if another OData service is chosen).
These are all read-only services, so I'm not concerned about maintaining any consistency of client-side update state.

It seems that when the DataServiceContext is set via a binding, the grid shows no data.

It seems that queries are never issued to the context:

System.ArgumentException: Could not find a matching query method on the DataServiceContext

Maybe the RadDataServiceDataSource is reflecting on the declared type of the bound property (DataServiceContext) instead of its runtime type (generated in the proxy and unavailable to me at design-time)?

[Wayne]

I think I see the problem. The RadDataServiceDataSource will only see query properties with an element type that implements INotifyPropertyChanged (which my generated proxy does not have). I need to figure out how to get EntityClassGenerator to generate the entity types with INotifyPropertyChanged support (which sucks because I don't actually need them to be editable).

[Wayne]

... which would appear to be controlled by the curiously-named property UseDataServiceCollection.

[Rossen Hristov]

Hello,

RadDataServiceDataSource does not support dynamically binding its DataServiceContext property because the DataServiceContext and the QueryName should be initialized "together" as it happens in the XAML parser (i.e. ISupportInitialize). If you change the DataServiceContext at runtime, the QueryName will still be the old one and you will get an exception because the new DataServiceContext may not include a query named like this. And vice versa -- if you change the query name first, the DataServiceContext will still be the old one and you will get the same exception -- "Could not find a matching query method on the DataServiceContext"

What you can do is use its underlying MVVM collection called QueryableDataServiceCollectionView<T> which accepts a DataServiceContext and a DataServiceQuery in its constructor. Each time the user selects a new DataServiceContext you can create a new instance of the QueryableDataServiceCollectionView<T> with the new context and the new query. You can expose this QueryableDataServiceCollectionView<T> from your view model and bind controls to it. Each time you change its instance you will raise a PropertyChanged event to let the world know that it has changed.

Our online demos have an example called MVVM Support in which you can see this collection in action.

I hope this helps.

Greetings,
Ross
the Telerik team

[Wayne]

Ross,

Actually, the reason I wasn't seeing any data was because my generated entity proxy types were not implementing INotifyPropertyChanged - the RadDataServiceDataSource requires this, and I was able to change my proxy generator to fix that. So now I have a proptotype working, but I'm sure you're right that if I bind a DataServiceContext that happens to not contain the current QueryName, I'll get errors. I can probably handle that in the ViewModel by resetting the QueryName (to null?) when the context changes, so that the user must select a query from the new context when it changes.

Your suggestion regarding QueryableDataServiceCollectionView<TEntity> may not be so simple for me since I actually don't ever know or care what TEntity is - the proxy entities are dynamically generated at runtime, so my ViewModel offers no entity-specific properties, only a DataServiceContext (source) and a string (queryname). I'd probably have to construct the QueryableDataServiceCollectionView<TEntity> with reflection. I suppose that wouldn't be so bad...

Thanks,
WMB

[Rossen Hristov]

Hello,

You are correct. If the DataServiceContext is null OR the QueryName is null or empty nothing will be attempted. Nothing will happend thus no exception should occur.

Here is our method that tried to located the query on the DataServiceContext by using reflection:

private bool TryUpdateDataServiceQuery()
{
    if (this.DataServiceContext == null || string.IsNullOrEmpty(this.QueryName))
    {
        return false;
    }

    this.QueryInfo = RadDataServiceDataSource.GetDataServiceQueryInfo(this.DataServiceContext, this.QueryName);

    return true;
}

So, if you nullify the QueryName before changing the context, nothing will happen at all. Then when your user selects the new context and then the new query, we will try to find it on the new context and load the data.

I hope this helps.

Regards,
Ross
the Telerik team