In my last post, I discussed how to get ExtJS 3.0 to work with Microsoft ADO.NET Data Services’ composite primary key syntax for REST URIs, which is likely the first challenge a developer will come across when getting the two to talk to one-another. Another obvious disconnect is the syntax for sorting and paging, as expected by Ext.grid.GridPanel and Ext.PagingToolbar.
Parameter Names. ExtJS gets us 80% there by making its parameter names configurable, using the Ext.data.Store paramNames object. This can be done using the following:
store = Ext.data.Store({
paramNames : {
start : '$skip',
limit : '$top',
sort : '$orderby'
}
...
});
Sorting. While the paramNames.sort property gets us close, it fails to accommodate one aspect of expected syntax, which is the fact that Data Services expects the direction to be appended (in lower case) to the sort statement. So, instead of the ExtJS default of "?sort=FieldName&dir=ASC", Data Services is expecting "?$orderby=FieldName+asc". In order to address this, we'll need to override the Store.load() method. As with the DataServicesProxy, most of this is out-of-the-box code; the key difference is the definition of options.params[pn.sort]:
Ext.data.DynamicDataStore = Ext.extend(
Ext.data.Store,
{ load: function(options) {
options = options || {};
this.storeOptions(options);
if (this.sortInfo && this.remoteSort) {
var pn = this.paramNames;
options.params = options.params || {};
//This is where the magic happens.
options.params[pn.sort] =
this.sortInfo.field + " " +
this.sortInfo.direction.toLowerCase();
}
try {
return this.execute('read', null, options);
}
catch (e) {
this.handleException(e);
return false;
}
}
}
);
As an aside, since we have to override the store class anyway, this is a good opportunity to also override the constructor and embed other Data Service defaults into the class, such as the paramNames set above.
Paging. As with sorting, the paramNames collection addresses a lot of the issues. There remains one glaring discrepancy, however, which is the fact that ADO.NET Data Services 1.0 doesn't provide a property for total count and, therefore, there is nothing to bind the JsonReader's totalProperty to.
There isn't much we can do with ExtJS to compensate for this, but fortunately Microsoft has an answer: ADO.NET Data Services 1.5 is scheduled to include this as an optional property. We're using Community Technology Preview (CTP) 2 at Ignia, although it's important to note that this is a preview version and that the syntax may change before the final release (which will likely ship with .NET 4.0). There are a couple of "gotchas" in setting up Data Services 1.5, such as setting environment variables and configuring the services; you'll want to watch the team's configuration video to ensure you've addressed those.
Once you've installed and configured Data Services 1.5, you'll need to ensure that your REST query includes the parameter $inlinecount=allpages; once this is done, you can configure your JsonReader to bind to the appropriate fields:
var reader = new Ext.data.JsonReader(
{ totalProperty : 'd.__count',
idProperty : '__metadata.uri',
root : 'd.results'
},
...
}
It's worth noting that when including the $inlinecount, all records are nested under a "results" collection, thus requiring your JsonReader's root property to be updated as well.
Related Posts: