New Path Editor for the Domain-Specific Language Tools (DSL Tools)

 

In the DSL Tools, paths are used in a DSL definition to specify how to navigate from one object in the domain to another. They are used in various parts of the DSL definition, such as:

· Compartments: a path specifies which elements will be displayed in the compartment ;

· Decorator maps: a path can be used to specify the object that has the property to display in the decorator;

· ExplorerBehaviour: paths are used to specify which nodes to hide.

The path syntax is described on the DSL Forum at https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=464793&SiteID=1. Basically, a path is composed of multiple path segments. Each path segment specifies a transition from an object to a link, or from a link to an object.

However, the path syntax, although simple, is not particularly easy to work with and the current authoring experience is quite basic – as you type the path into a textbox, the individual segments of the path are checked and a tooltip is displayed if the path segment is invalid. The path as a whole is not checked until the validation rules are run against the model (e.g. by right-clicking on the design surface and selecting “Validate”), so it is possible to enter an invalid path in the textbox.

CTP 2 of the VS SDK for Orcas Beta 1 adds a richer path editing experience to the DSL Designer in the form of a drop-down tree control. You can now either type the path syntax as before, or you can drop down the control to display a tree of all of the valid paths from the current starting point.

This screen shot shows the path editor for a Task element in a language created using the Task Flow template:

The tree displays one or more root nodes, each root node representing a valid starting point for the path. In most cases, there will only be one valid starting point. For example, when specifying the model elements to display in a compartment, the starting point is always the DomainClass that the CompartmentShape containing the compartment is mapped to.

Each child node in the tree represents a domain class or link that can be transitioned to from the parent node, so you can build up a valid path simply by starting from the appropriate root node and navigating down through the child nodes until you reach the domain class or link you want to end at. Selecting the end-point node collapses the tree control, and the appropriate path syntax is shown in the text part of the control.

The tree control also enforces some other restrictions:

· A limitation of v1 of the DSL Tools means that a path may only contain one relationship that has a multiplicity of “many”. If you have selected a node that represents a “many” relationship, then there will be no more “many” nodes under that node.

· Paths of the form “A->B->A”, although valid, do not make sense in practice, so the nodes displayed by the tree won’t allow you to create paths like this. However, if you really want, you can still create “no-op” paths of the form A->B->C->B->A (!).

For performance reasons, validation rules are not run every time a path changes, so there are still some circumstances in which a path created with the editor may later fail validation (although these should be uncommon). Overall, however, the path authoring experience should be much simpler and quicker. Please try it out and let us know what you think!

Comments

• Anonymous
  June 07, 2007
  Over on the Team Architect blog , Duncan Pocklington discusses the way cool new path editor UI in Orcas

• Anonymous
  June 08, 2007
  Nice description of the new path editor for DSL Tools on the VS Team Architect blog .