Outputting Code - Understanding Script Directives
(Page 2 of 19 )
The script you’ll use for one-click code generation is an Extensible Markup Language (XML) file that contains a series of directive elements. Each directive is an XML element that describes a single, atomic step run by the code generation script. You can create and edit the script file through the harness or through an XML editor. To support editing in either manner, the XML script used by the harness follows an XSD schema that you can extend.
NOTE: Appendix A shows the XSD schema used by the harness script as an example. This lets you look at its details, even if you aren’t already familiar with XSD. |
Each directive includes many attributes that specify different aspects of processing one atomic step. Child elements of the directive logically group attributes based on what they relate to. For instance, there’s a set of attributes related to processes that produce multiple files. The MultiPass child element contains selection and naming criteria that can be used by XSLT generation, brute-force generation, CodeDOM generation, and SQL scripts. This grouping of attributes within child elements allows abstraction of the child element definition for use by multiple directives, significantly easing the maintenance burden for the XSD. For example, the basic information required of all directives is contained in a child element named Standard that contains attributes such as a human-friendly Name. It also includes a Checked attribute indicating whether the directive is checked in the TreeView of the harness, where all checked elements are processed.
Groups of directives are called sections. Sections let you group processing based on any convenient criteria. You might group directives by the generation step they correspond to or by the processing performed by different people, or you might group directives to provide alternate scripts for testing. You can turn processing on and off for entire sections when you run the generation harness. This is an example of a single section with a single directive and three child elements:
<kg:Section OutputDir="VBCode/Test">
<kg:Standard Name="PreProcessing" Checked="true" />
<kg:CreateMetadata Server="localhost" Database="Northwind">
<kg:Standard Name="NorthwindExtraction" Checked=" true " />
<kg:SinglePass OutputFile="[BasePath]Metadata Files\Northwind.xml" />
<kg:OutputRules HashOutput="false" OutputFileType="XML"
OutputGenType="Overwrite" />
</kg:CreateMetadata>
</kg:Section>
In this sample, the directive is CreateMetadata. The CreateMetadata directive and the Section each contain Standard child elements that contain the name and checked status. The checked status indicates whether the item appears checked in the TreeView and whether that step will run as part of code generation. The CreateMetadata directive contains two additional child elements, each of which contains a logical group of information required for processing. There are about ten directives for full-featured code generation, as well as several groupings of attributes in child elements. Chapter 5 discusses specifics of each directive and child element.
Using the Code Generation Tool The code generation tool does only two things. It puts a friendly face on editing XML, and it performs code generation by executing your script. To perform code generation, the tool executes code based on the XML directive elements that make up your harness script. This code may be in an external assembly you reference in a script directive.
The tool’s XML editing feature is generic and based on the XSD. The attributes of the XML harness script become controls on the harness’s form, and the child elements become grouping boxes.
NOTE: I don’t promise it’ll edit any XML file you throw at it, but it’ll edit XML you need for scripting code generation directives and may edit other XML files if you have XSDs for them. It’s an object-oriented design, so if you have a similar need, you can customize this form through inheritance. The harness user interface also uses some cool dynamic techniques you can walk through in Appendix C. |
You start the tool by double-clicking CodeGenerationHarness.exe in the Tools subdirectory. (footnote 1) Selecting File -> Open lets you open a script such as Harness3.xml in the Chapter 3 subdirectory. When you open this file, you’ll see a TreeView containing sections and directives. As you select different nodes, that node will appear for editing in the right pane. Figure 3-1 shows the user interface for this tool. From the File menu you’ll be able to do familiar actions such as save and create new files. New files are created based on the XSD. The standard XSD for code generation is called KADDrivingMetada.xsd and is in the XFiles subdirectory of the book’s code directory.
Figure 3-1. The code generation harness with a sample XML file open to an XSLTGeneration directive
When you click the Run button, all the currently checked directives are processed. After processing is complete, the Result tab contains any errors or warnings that occurred during processing.
Footnote 1. Feel free to create a shortcut and put it on your Desktop or Start menu. The downside of XCopy deployment is that this doesn’t happen automatically.
NOTE: If you modify XSLT files and save the updates, code generation will use the updated files the next time it runs, regardless of whether the harness has remained open. However, you won’t be able to compile assemblies that you reference as processes until you close the harness. This happens because the assemblies remain loaded. You have to stop and restart the harness when you make changes to brute-force or CodeDOM templates. |
 This chapter is from Code Generation in Microsoft .NET by Kathleen Dollard (Apress, 2004, ISBN: 1590591372). Check it out at your favorite bookstore today.
Buy this book now. |
Next: Understanding Other Features of the Generation Harness >>
More .NET Articles
More By Apress Publishing
