Update: check also Steven Kelly’s (from Metacase) review of the book.

I’ve just finished to read the book Domain-Specific Development with Visual Studio DSL Tools (Addison-Wesley, 524 pages). Since it was written by the creators of the DSL Tools, it contains a valuable amount of information on the subject.

Although it has some small mistakes (such as a few wrong names used to reference items in the examples and some pictures which were interchanged), it can be considered the best study resource currenly available if you want to go a level deeper into the DSL Tools.

I would also love to have more "tutorial-based" explanations on some subjects, but in general the book provides a nice coverage regarding the many topics of the DSL Tools (conceptual modeling, designer appearance and behavior, serialization, validation, deployment, etc.).

While reading, I took some notes on cool things one can do using the DSL Tools, some of them which I was not aware of. I’ve ended with a list of interesting points, which I was not covering in my DSL presentations, articles and posts before*.

I was desiring to document such an (incomplete) list somewhere, and I’ve chosen this blog to do so. Therefore, here you have the list. Each bullet starts with the hidden text "With the DSL Tools, you can…"

General

• [pg. 002] Understand that, in domain-specific development, the fixed parts of the products will generate reusable frameworks in the product line, while the variable parts will result in the creation of DSLs.
• [pg. 008] Understand that a specific-domain can be horizontal (workflow, web, etc.) or vertical (games, telephony, etc.).
• [pg. 032] Customize your final product (DSL + DSL API + validators, etc) using different customization levels from the easiest one to the most powerful one.

Domain Model Definition

• [pg. 118] Use special classes such as DomainClassInfo, DomainPropertyInfo and DomainModelInfo to programmatically access the meta-information of DSL elements.
• [pg. 120] Create an element name provider to define how the names of recently-created concept instances (ex.: Level1, Level2, Level2, etc.) will be built.
• [pg. 121] Have calculated properties (Kind = Calculated), i.e., properties whose value are calculated from "outside" data such as other properties.

Presentation

• [pg. 139] Use exposed style properties to define which properties related to the appearance of a DSL diagram (Text Color, Fill Color, etc.) can be actually changed by the DSL user (developer).
• [pg. 142] Create custom editors to, for instance, define an alternative design surface for your DSL, such as a Windows Forms control.
• [pg. 173] Use multiline text decorators to textually decorate shapes related to DSL concepts. 
• [pg. 174] Change the image displayed in an image decorator dynamically (variable image shapes).

• [pg. 176] Set a background picture for a DSL diagram. 
• [pg. 177] Suggest specific connection points to connect shapes.
• [pg. 178] Change the routing style of connectors, not being restricted to the options presented in the properties windows (straight and rectilinear). 
• [pg. 184] Hide or customize the appearance of nodes in the language explorer window.
• [pg. 192] Use custom type descriptors to show a property of one concept in the properties window of other concept.
• [pg. 193] Have a custom properties window to edit a concept property. For example, it can be a file picker or a windows forms you’ve implemented earlier.

Creation, Deletion and Update Behavior

• [pg. 200] Use element merge directives to control what relationships are constructed when one element is merged into another (for example, when an element is dragged from the Toolbox onto the diagram surface).
• [pg. 207] Forward element merge directives from one element to another (sending the element to be merged onto a different target).
• [pg. 208] Turn on the "uses custom accept" flag on an element merge directive to write code to have extra control over wheter a merge can be done. For example, we can use this to define that only 5 instances of a given shape can be added to the diagram.
• [pg. 213] Use custom element tool prototypes to add a group of elements (not only one) when the DSL user drags an item from the Toolbox onto the diagram.
• [pg. 217] Define possible source and targets of a link.
• [pg. 219] Use the same toolbox connection tool to create one of many relationships, depending on the context.

Serialization

• [pg. 237] Define how you DSL instance is serialized.

Constraints and Validation

• [pg. 295] Provide hard validation constraints to avoid users from doing some action in the DSL Diagram.

• [pg. 296] Use rules to disallow attempted changes on the DSL diagram or propagate changes through the model.
• [pg. 299] Use soft and hard constraints together to provide a better validation experience.

Generating Artifacts

• [pg. 325] Use real code first to then create a code generation template. 
• [pg. 347] Use utility methods in code generation templates, such as Write(), WriteLine(), Error(), Warning(), PushIndent(), PopIndent() and the Store property.
• [pg. 359] Generate multiple artifacts from a single text template (such as multiple classes generated from a single class diagram).

Advanced DSL Customization

• [pg. 398] Set the "generates double derived" flag to use the Generation Gap design pattern to extend your DSL, which makes it possible to override the methods of a given DSL element.
• [pg. 399] Set many customization switches to further extend your DSL.
• [pg. 401] Provide many custom overrides to change de behavior of the designer (CanFocus, HasShadow, OnDoubleClick, etc.).
• [pg. 417] Handle Store and .NET events to further extend your DSL.
• [pg. 420] Use Bound Rules to constraint the location or dimensions of a shape in response to a user gesture.
• [pg. 429] Add a set of menu commands to your diagram.
• [pg. 435] Embed a DSL diagram inside a standard Windows control.
• [pg. 437] Copy and paste DSL elements from and to the clipboard.
• [pg. 442] Have a DSL diagram shape to contain other shapes.

Deployment

• [pg. 373] Use a built-in setup project to create a installer for your DSL.
• [pg. 390] Deploy text templates (generators) along with your DSL.

Designing a DSL

• [pg. 455] Choose an approach to create a DSL: top-down (from the DSL to the common framework) or bottom-up (from the framework to the DSL)? It is effective to alternate between top-down and bottom-up techniques, working incrementally to avoid the risk of a big upfront investment but occasionally standing back to check for consistency.
• [pg. 458] Understand that feature trees are an approach to better study the products belonging to the domain and plan the product line, including the DSL and the reusable, common framework.

As you can see, that’s a pretty amount of information! Each bullet would be the main topic of a blog post…

I’ll probably consult this post whenever trying to add additional features to the SharpLudus project, and perhaps you can do this to your DSL-based projects too. Hope to keep up the discussion soon.

* You can refer to this article here [pt-BR] to get introduced to the DSL Tools, or search for my DSL Tools Webcast [pt-BR] in the MSDNBrasil Media Center. Yes, I know it is strange to use pt-BR resources in a blog written in English, but the trend is that more and more English language resources are created in the future. That’s the cost of a language migration.

[]s
— AFurtado