Advanced Query API (in javascript!)

We're seeing a lot of downloads of our current WW.DataServices version. Those people are enjoying a tool that automatically builds their back ends for them, including a SOAP Web Service layer. That's just the beginning though.

This upcoming release (soon, I promise), has much more. In this post I just want to briefly describe the Query API, which is a series of new web methods in the WW.DataServices auto generated web service layer, as well as an auto generated javascript data entity layer designed to make it super simple to query your data from a Rich Internet Application front end. This means your back end will be instantly mashable! Just think for a minute about how powerful that is.

Ok, now let me show you a bit of code to explain the kind of power I'm talking about.

var customers = Northwind.CustomerCollection();
customers.showGrid();

You'll be able to write the above javascript in order to query your web service, get all the customers, and display a rich grid (based on extjs.com). All the AJAX, web service proxying, wiring, JSON/XML serialization, etc. will be handled for you automatically. Furthermore, the grid that gets displayed will include, out of the box, a search box toolbar, pagination, double clicking a record to pop open an auto generated form for editing, and of course sorting. All with just two lines of code (see screenshot below)...

So, now what about something a little more interesting? Now let's say we want to get a list of territories and their corresponding region names, but only where the RegionDescription property is "Western". We then want to set the initial sort order to be on the TerritoryDescription column, descending. Finally, we want to page the dataset, starting with the first page of 5 records, and display the results in a rich grid. Note that we are talking about a join query across two tables... check out the below mashup enabling javascript:

var territories = new Northwind.TerritoryCollection()
.select(["TerritoryDescription as Description", 
  "Region.RegionDescription as Region"])
.where("Region.RegionDescription","=","Western")
.orderBy("TerritoryDescription DESC")
.setPagination(1,5);

territories.showGrid();

In the above code (apologies for odd line breaks due to the blog stylesheet), please take note of the following niceties.

• First of all, we are able to intuitively build up our query using a series of chained calls. Notice that javascript allows us to continue a single line of code simply by placing the dot on the next line. This is merely a convenience that us seasoned js pros take advantage of. You could just as easily have written the query in multiple lines of code, as each of the methods returns the underlying data entity.
  
  
• Secondly, we can specify, via the .select() method, an array of column names we want to have the webservice return in our data collection query. The webservice will smartly serialize only the columns you explicitly request in order to optimize bandwidth and wire overhead.
  


• Next, notice that we are able to alias the columns using the "as" keyword (in our example we're aliasing "TerritoryDescription" as "Description".
  


• Now for the really cool part, notice the intuitive manner in which we are able to jump across to another table (i.e. join). You do this simply by using dot notation in the form of TableName.ColumnName. Behind the scenes the webservice back end will automatically build the appropriate joins for you.
  


• Moving on, we can filter the dataset using the .where() method, set the initial sort order, and even specify pagination options. In this example we're saying "start on page 1, and give me 5 records per page"

And the resulting rich grid is shown below:

Finally, I just want to show one more screenshot, and that is of the auto-generated form you will get when you double click a row in one of these grids...

Notice in the above picture, that the forms are also rich by default, and automatically figures out foreign key relationships in order to display type-ahead paginated comboboxes as appropriate. By default, these widgets (grids, forms, trees, etc) can take advantage of the automatic windowing system (notice our form is actually a modal dialog), but of course all of these behaviors are overridable by you.

This was just a sampling of the types of things you'll be able to do. In closing, did you happen to notice that we never had to "bind" a proxy to the web service in the back end? That's because we do that dynamically behind the scenes as well. Gone are the days of having to re-deploy clients every time a service contract changes... That is if you're using WebWidgetry :)