Those of you who have downloaded the June CTP of DSL Tools will, by now, be aware of quite a few changes. In particular you’ll have noticed that we’ve replaced the old .dd and .dmd formats with a single .dsl format, and provided a (currently unfinished) designer for this format.
Whilst we’re waiting for the documentation to catch up, I thought I would spend a few cycles telling you about the new .dsl format, and provide some insights into some of the thinking behind it.
So where to start. Well, it’s probably a good idea for you to take a look at a .dsl file. Follow one of the walkthroughs in the documentation that comes with the kit to get hold of an example.
If you open the file in the xml editor, you’ll see that it contains definitions for: classes, relationships, types, shapes, connectors, a designer, a diagram, plus sections to define xml serialization and explorer behavior, and a section to define things called connection builders.
Looking a bit deeper, you’ll see that a diagram defines shape maps (various kinds) and connector maps, that is, how shapes and connectors map to classes and relationships for that particular style of diagram.
You’ll also see that, as well as referencing the diagram to be used, a designer also defines one or more toolbox tabs, with tools on them.
I’m going to focus in this post, and probably a couple after, on one of the key changes we’ve made, which is to make a clear distinction between how information in the model gets presented on the diagram, and the actions used to create new parts of the model.
In the old dd format, you defined a shape, a class, and a map from class to shape, then a tool that referred to a shape. In the designer that was generated, using the tool caused an instance of the mapped class to be created together with an instance of the shape to view it. This scheme had the advantage of being simple, but the disadvantage of being very inflexible. Without a lot of custom code, you couldn’t define (element) tools that did anything other than create an instance of a class embedded in the object mapped to the diagram with a new shape on the diagram viewing it. A restriction of this scheme was that it forced most classes in a domain model to be directly embedded in the root class.
In the new format, the shape and connector mappings only govern how a diagram views the model: what shapes get created to view what model elements, and what connectors get created to view links of what relationships. The tools, in conjunction with merge directives and connection builders, govern how model elements and links get created in a model. An element tool refers to a class. It causes an element of that class to be created and merged into the model via the element mapped to the diagram or shape that the tool is dragged onto. Merge directives on the class of that latter element define the mechanics of the merge. A connection tool refers to a connection builder, which defines how the element mapped to the shape at the source drop point of the tool gets connected in the model to the element mapped to the shape at the target drop point of the tool.
So we now have a definition in the style of the well-known model-view-controller pattern. Tools are the controllers, and are used to add stuff to the model, whose elements are viewed by shapes and connectors on the diagram, as determined by the shape and connector mappings defined for that diagram.
Combined with the use of paths in the definitions of maps, connection builders and merge directives, plus the ability to flag the need for custom code at various key points, we end up with a very rich and flexible system for defining the interaction between the design surface and the model.
In the next post, I’ll walk through an example. But for now, I’ll point you at a great post by Alan the reveals some of the details of paths, merge directives and connection builders.