Introducing SPML

In today's post I'd like to introduce a new concept that will be introduced in LINQ to SharePoint v0.3: SPML or the SharePoint Mapping Language. It didn't make it for the 0.2 release due to time restrictions, but tonight the first portion of the POC code has been checked in to CodePlex. So what's it?

Let's start with the very beginning: SpMetal. As you might already know, the SpMetal tool is used to generate entity classes from a SharePoint list definition. It connects up to the SharePoint site, grabs the list definition and converts it into some entity class type that can be used to write queries using SharePointDataSource<T>. Therefore, the core of its work is to generate code either in C# 3.0 or VB 9.0. To set our minds, here's a little sample:

image
The syntax of SpMetal

image
A list with various fields

image
SpMetal in action, exporting the Demo list

image
Code generated by SpMetal

In the very first alpha of LINQ to SharePoint (before we went live on CodePlex), there was no such tool at all and the creation of entity classes was a manual job (after all, it wasn't so difficult at all yet: there was no base class to derive from and using automatic properties in C# 3.0 the mapping was just a matter of minutes). Lazy as developers (including myself) are, the SpMetal tool was created as a very simple tool based on a quick-n-dirty string concatenation and formatting technique (take a look at the sources to see how it's done in 0.2). However, things were getting more complex and a few weeks ago work was started to port the tool to a CodeDOM-based approach for code generation. I decided not to merge these changes with the 0.2 release since full testing on the tool's correctness hasn't been done yet, so it will become part of 0.3 instead.

However, there's more than just a new back-end to SpMetal. The cool thing about it is its potential for reuse elsewhere, including the VS 2008 IDE. Over time, the goal is to provide entity creation as easy as dragging and dropping lists from an add-in in Server Explorer to a designer surface. We're not there yet, but an important milestone is under development right now: SPML. Designers are just overlays on top of some source definition, for example a partial class with Windows Forms designer generated code or a resx file or ... In a similar way, SPML is the source-side of a SharePoint list mapping for LINQ to SharePoint. Currently it's very minimalistic, but over time it will get more and more expressiveness to drive the mapping process (e.g. you'll be able to decide which fields to include in the entity mapping and you'll be able to control a few aspects associated with entity updating, another 0.3 feature that's under development right now). Let's take a brief look at it:

image

Observe a few things:

  • The file extension of an SPML file is .spml (duh!).
  • SPML files contain the definition of a SharePointDataContext, something that will be introduced in 0.3 (I'll blog about it once we get closer to 0.3). For now, think of it as a set of list entities (see <Lists> section).
  • The SPML file has a Custom Tool associated, called LINQtoSharePointGenerator. You can specify a code namespace as well.

What the LINQtoSharePointGenerator does is pretty straightforward: it parses the SPML file, finds enough information to connect to the WSS site and lets the SpMetal back-end (now called the EntityGenerator) do the rest of the work, returning a code file (support for VB and C#) that's added to the solution. Furthermore, it adds a reference to BdsSoft.SharePoint.Linq if it's not already present. All of this magic is done automatically when you build the project (or you can trigger it manually). This means that using LINQ to SharePoint doesn't require SpMetal anymore: just write an SPML file and add it to the project with the right Custom Tool setting. Here's an example:

image
Manual triggering of the LINQtoSharePointGenerator...

image
...the result: a .Designer.cs file

image 
With VB support included!

image 
Start to write LINQ queries right away

If you want to play with this already, you can grab the sources from CodePlex (change set 7418). However, the VS Orcas integration requires you have the VS Orcas SDK installed as well. Also remember this is very early work in progress but step by step we're getting there.

Enjoy!

Del.icio.us | Digg It | Technorati | Blinklist | Furl | reddit | DotNetKicks

Published Wednesday, July 04, 2007 1:00 AM by bart
Filed under:

Comments

No Comments
Powered by Community Server (Non-Commercial Edition), by Telligent Systems