Designers and VSTS

This chapter has covered a simplified navigation designer concept that would enable users to model the navigation of an application or website. Abstracting from the end technology, it could be extended in any direction to allow for modeling of different semantics, such as auditing and logging.

In Part IV in this book, we describe how you can build your own custom Work Item types for use by Team System. The process you've already seen is fairly cumbersome in that you have to construct an XML document adhering to the supplied WIT schema.

This in itself is fine, but a Work Item type can become incredibly complex when you have to start modeling the workflow around State Transitions, which is very hard to visualize and understand when it's represented in an XML file format.

You could easily define a language model for Work Item types and construct a designer using the DSL Tools. The only code you would need to write would be code to translate the XML file format of Work Item types into the language model and back again.

This translation section would be very easy to implement; you could use XSD.EXE supplied with the .NET Framework to create a .NET object model from the Work Item Schema, load the XML into this object model, and iterate through all of the concepts, constructing the equivalent language model elements allowing the user to visualize the Work Item structure in the designer. Saving changes would be the same process but in reverse.

Apart from the translation code, you won't have to write any other code, which is very compelling when you consider how much code you would have to write yourself! A screenshot of a prototype WIT designer that one of the authors has developed is shown in Figure 6-19. States are represented by the boxes on the diagrams. Fields in the domain model are not represented as boxes but as dynamic toolbox items, and transitions between states are represented by the lines between states.

Figure 6-19