When talking to colleagues about Microsoft “Oslo” M and MGrammar in particular, I’m often asked whether there is a practical problem Oslo solves and how a developer plugs Oslo into their application. In response, I always point out the samples, blogs, presentations, and documentation.
I find though, that colleagues become a bit overwhelmed with the new ideas and wealth of information. Mostly, they’re looking for a single starting point-something akin to a simple sample solving some practical problem and a detailed explanation of how it’s assembled. Using a sample WPF application, I’m going to provide this starting point so you can start thinking about how Oslo M could solve your business problems.
Olso Overview
If you’ve been following my articles, Oslo’s goals and technologies should be familiar to you. If not, here is a summary.
Oslo is composed of the following components displayed in Figure 1.
Figure 1 Oslo Architecture (Source: “Microsoft PDC 2008 – A Lap Around Olso”)
- “M”, a language for composing models and DSLs
- The Repository a SQL Server database designed for storing models
- Quadrant, a tool for editing and viewing model data
Currently, Quadrant is only available to PDC 2008 attendees. M and the Repository come with the Oslo SDK available on the Oslo Developer Center site http://msdn.microsoft.com/en-us/oslo/default.aspx.
Oslo’s goal is to deliver a foundation for building and storing models of all types. Models are application metadata formatted for runtime consumption. Separate Microsoft initiatives aim to build runtimes and tooling into applications like Visual Studio that are Oslo model aware.
The M Language is composed of MSchema, MGraph, and MGrammar. A complete introduction to M is beyond the scope of this article. I introduced MSchema, MGraph, and MGrammar in my prior articles, you can read them here.
There is an underlying set of .NET Framework classes supporting all the functionality above. In this article, I’ll employ some of these classes in a sample application.
Sample Application
There are two parts to the sample application: a WPF EllipseGeometry path animation and a Domain Specific Language (DSL) written in MGrammar for controlling the animation. The sample application is built on top of the January 2009 Oslo SDK CTP. A screen shot of the sample application appears in Figure 2 below.
Something you may have noticed in the Oslo introduction above is that Oslo provides the infrastructure, but the Runtime consuming Oslo is the solution. Essentially the sample application is a runtime for a DSL. So a likely question is why did I employ a DSL?
Why the DSL
A DSL is commonly defined as a sort of programming language performing a specific purpose and possessing limited language capabilities. So according to the definition some languages defined as DSLs are: RegularExpressions, TSQL, and configuration files. At first a DSL may appear to be an odd choice for controlling animation. When considering the requirements below, a DSL seemed a perfect fit.
I needed to store key X, Y coordinate positions along the animation path, so I needed some representation I could easily read and write from a file. I didn’t want to store precise coordinate positions. I wanted positions to scale according to the dimensions of the user’s monitor and the application window. So user’s importing the animation in an application with a larger screen or application window would view the animation scaled in proper proportions.
I wanted to build something simple for a user to compose. First, I didn’t want the user to think about where, for example, coordinate (30, 100) fell on the screen. I wanted the user to think more about the direction of the animation and how far the ellipse should travel before switching directions. Second, I ruled out something like XML, because I wanted the commands to look and feel like natural language.
With an understanding of the application and the motivation behind the application features, I’m going to demonstrate how the sample works, starting with an overview of the major classes.