Overview of Domain Path Syntax
Domain-Specific Language Tools uses a unique path syntax to locate specific elements in a model. This syntax takes the following format: ExampleElementReferencesTargets.Targets/!Target
ExampleElementReferencesTargets
.png)
This format follows the tree of the model. For example, ExampleElementReferencesTargets in the previous illustration is a domain relationship, and Targets is the value of the Property Name property for one of its roles. The segment /!Target designates that the path finishes on elements that the role Target (Property Name of Sources in the illustration) accesses.
The Name property of a role is the name that is used in programming to navigate from an instance of a domain relationship to one of the domain classes that it connects. The Property Name property of a role is used to navigate from an element to the element or elements that are linked to it by the relationship.
The path syntax is simple but verbose. The shape map in the Component Models solution template is an example of this syntax. Start by creating a domain-specific language that is based on the Component Models solution template in the wizard.(For more information, see How to: Create Domain-Specific Language Solutions.) This solution template maps InPortShape to InPort. Then open the DslDefinition.dsl file in Solution Explorer. In DSL Explorer, expand the Diagram node, expand the Shape Maps node, and click the first shape map, which is called CommentBoxShape. Details for this shape map appear in the Properties and DSL Details windows.
Hinweis
If the DSL Details window does not appear, click DSL Details on the DSL Designer toolbar.
After you click a shape map in DSL Explorer, the parent element path appears on the General tab of the DSL Details window.
Slashes separate the syntax of a path. Each segment is either a hop from an element to a link or from a link to an element. Segments frequently appear in pairs. One segment represents a hop from an element to a link, and the next segment represents a hop from the link onto the element at the other end. (Any link, which is an instance of a relationship, can also be the source or target of a relationship itself. However, most paths delineate link/element/link/element...)
Each segment starts with a relationship name. If the hop is from an element to a link, the path segment appears as "Relationship . Property". If the hop is from a link to an element, the path segment appears as "Relationship ! Role".
In the example of the InPort shape map, the parent element path starts as follows:
ComponentHasPorts.Component
If you view the DslDefinition.dsl file as a diagram, you can determine that InPort is a subclass of ComponentPort, InPort has a relationship ComponentHasPorts, and the property is called Component.
When writing C# against this model, you can jump across a link in one step by using the property that the relationship generates on each class that it connects:
InPort port; ... Component c = port.Component;
However, you must specify both hops explicitly in path syntax. This requirement makes it easier to access the intermediate link. The next hop jumps from the link to the component:
ComponentHasPorts.Component / ! Component
(You can omit the relationship name where it is the same as the previous segment.)
The name that you use for the element-to-link hop is the value of the Property Name property that is defined on the role. That name appears on the main diagram, next to the corresponding line from the element's domain class. If you click that role line, the name appears in the Properties window as the value of the Property Name property.
The name that you use for the link-to-element hop is the role name that is defined on the relationship for the destination end. In the diagram for DslDefinition.dsl, if you click the line on the other side of the relationship, the name appears in the Properties window as the value of the Name property for that role.
In some contexts, such as element merge directives, only the element-to-link segment is required.
See Also
Concepts
Overview of Element Merge Directives