Beginner question about the use of DSL Tools

I have what's probably an incredibly dumb question on the purpose of DSL tools, but I'll ask it anyway. I'm going to describe what I think DSL Tools offer and I would really appreciate if someone could confirm whether I'm on the right track or whether I'm completely out to lunch (and if so, kindly correct my thinking).

The domain model designer allows me to create what is effectively the language: the set of concepts (which map to classes) and their properties (attributes), relationships (simple, containment, inheritance) between concepts, and probably some further constraints on the concepts. Additionally, in the same solution that allows me to define my domain model, I can define things like notation and UI widgets that will appear in the designer, which I declared in an XML file based on the domain model, which the end user will later use.

Here's the part where I'm possibly most lost. Once the domain model is defined, and the visual elements of the designer are specified, I can run all the templates, and build the solution. At this point, I start a new instance of Visual Studio (in the experimental hive), and suddenly a new designer is available for use. This designer was declaritively created using an XML file earlier (in the same solution in which I defined the domain model) along with various resources and such. The user of this second instance of Visual Studio can choose this new designer from the New Item template. The user can use widgets in the toolbox to specifies concepts and relationships in the designer based on the domain model I earlier defined. The property grid can be used to modify attributes of these concepts. The act of dragging items (concepts) from the toolbox, setting properties, and specifying relationships is effectively entering data into the system. That is, rather than having a win32 app that has numerous text fields that the user enters data into, in this case the end user enters data by using the toolbox items and properties grid. Is this correct?

Now that the user has entered data, the text templating engine can be used to perform actions based on the entered data. For example, in the walkthroughs templates are written that generate HTML pages that have embedded C# or VB portions of code which are executed to make part of the HTML file output. This is similar to the ASP model. Right now, the output of these tempatles is either a text or HTML file. Am I on the right track?

At some point, the Guidance Automation Toolkit, may be used as a replacement or to supplement (complement?) the text templating engine to define behaviour based on the user data. Apparently a demo with DSL Tools and GAT was presented at Tech Ed '05. (I'd love to know more details on this).

Thank you for any clarification you can give!!

[2860 byte] By [Notre] at [2007-12-16]
# 1
Notre,

That's all pretty much right.

The biggest mind-bender for beginners (and us, sometimes) is the distinction between the Author and the authoring tools defining the language; and the User of the language, and the tools for editing that. It gets even more complicated when the User has tools for generating more code....

Where you say "rather than having a win32 app that has numerous text fields that the user enters data into, in this case the end user enters data by using the toolbox items and properties grid" yes, that's correct. In addition, the User can draw lines between the boxes items.

The outputs of the templates can be any text -- html, text, C#, VB, Java, newspaper articles, or more XML - for example to configure a software framework.
For example, suppose you're an ISV who specialises in business workflows systems. You get fed up hand-coding every system for each new customer, and hand-coding changes for your existing customers. So you author a workflow definition language -- maybe it's a diagrammatic language with icons for workstations, for workitems, for routes between workstations, and entities and relations for defining the data held in the workitems. Then you reorganise your workflow software into a generic framework that can be parameterised by XML or code generated from the workflow diagrams. (Actually, this is probably a much bigger job than defining the language -- and in practice, it has to be an evolutionary process.) Then when your next customer comes along, you begin by using your workflow language to write a description of the customer's business flow. You generate some config files or code from that, which you feed into your framework. In practice, this probably only handles part of what needs to be customized, and you still need to hand-code some; but it does a good chunk of the work. And when they change their process, you can respond with a lot more agility. Your business gets bigger, you hire more developers, and they're pretty soon all using your Workflow language as Users. You evolve the framework and the language to tune it better to your market.

GAT and DSL Tools complement each other - they're part of the overall "Software Factories" strategy. A language specific to your domain is only part of the story about speeding up your work. GAT helps you (as Author) provide context-specific menu items and templates within Visual Studio, so that your Users can speed up repetitive tasks that are particular to your framework architecture.

We will at some stage publish more substantial examples of DSL Tools (and GAT) in use.

AlanCameronWills at 2007-9-9 > top of Msdn Tech,Visual Studio,Visual Studio Extensibility...

Visual Studio

Site Classified