Finishing off the generation of the SQL for the physical schema means finishing the XSL templates and using the <xsl:document>
directive to generate two filesone for the SQL for the schema and the other for a file that contains SQL to insert the test data into the database. This is shown in Figure 2.
Figure 2. Building SQL: Adding the test data into the schema. Click on each template to see the code.
The XSLT files for the SQL generator are <<mysql.xsl>>, the main XSL template, which calls out two helper templates: <<mysql_create.xsl>> builds the SQL create calls and <<mysql_insert.xsl>> creates the SQL insert commands to add the test data into the schema.
With the database schema in place the next step is to lay database access layers on top of it with PHP and C#. I'll start with the architecture of the PHP solution.
The PHP architecture that the generation solution supports is a three-tier architecture with the database at the bottom, a second tier of database access, and the user interface in the first tier. This common and well regarded architecture is shown in Figure 3.
Figure 3. A Common Plan: The three-tier PHP architecture.
The highlighted elements in Figure 3 will be produced with code generation. The database access layer and a set of test pages for that layer will be built by the PHP generator. To finish off the application all that is required is the production user interface on top of the data access layer.
Generating the data access layer and the test pages will be done with one XSL style sheet that has four related style sheets.
The relationship between the style sheets is shown in Figure 4. The <<php.xsl>> style sheet is the central hub of the code generation system for PHP. <<php_db.xsl>> builds the ssdb.php file, which is a set of functions written on to of Pear::DB to make database access easier. <<php_lib.xsl>> contains the code for the database access classes that are created, one per table. <<php_test.xsl>> builds the test pages for the data access classes. <<php_index.xsl>> creates the index.html page that points to all of the test pages.
Figure 4. Style: The PHP stylesheets are shown. Click on each template to see the code.
Once the style sheets are run on the input schema the phplib directory will contain the data access classes. This directory needs to go somewhere in the PHP path. To finish off, the test pages then need to go into the Apache document root.
Now comes the fun part: showing how one abstract design specification can build code in very different technologies.
C# can talk with MySQL through the ODBC interface, so we can reuse the MySQL generator to build the database schema. The XSLT generator for C# only needs to build classes that act as a database access layer and test pages that use these database access classes, as shown in Figure 5.
Figure 5. Saving Steps: You only need to build the database access layer.
To complete the application you need to add pages to complete the user interface and add any custom business logic that you need.
The XSLT generator for C# takes a database schema as input and uses a set of four templates to generate the data access layer. The central template is <<csharp.xsl>>, which calls out to the three other template files (see Figure 6). The <<csharp_class.xsl>> template builds the C# classes that wrap each database table. The <<csharp_test.xsl>> page builds the test ASPX page which calls out to each class. The <<csharp_index.xsl>> template builds the index file that links to all of the test pages.
Figure 6. See Schema: These templates each play a role in generating the final ASPX page. Click on each template to see the code.
Despite the dramatic differences between the two languages we can use a single generation mechanism and a single schema definition to generate both sets of code and test pages
Keep an Eye Out
There are some drawbacks. For one, XSLT is not Turing complete, so you may need to do some pre-processing on the XML before you send it to the templates. Or you could embed an XSLT processor in your favorite language to handle the shortcomings in XSLT. But in this article I generated code in two different languages with XSLT alone, so don't be overly gunshy.
Another issue is the cumbersome syntax of XSLT and the encoding that must be used in the templates that sometimes obscures the code being generated. Both of these are ameliorated by XSLT tools and by the fact that XSLT is a standard that other engineers can understand and embrace.
The abstraction benefits of code generation allow for true cross-technology portability. Other generators, such as ArcStyler, have taken this much further, but the point is the same: XSLT is something that you can use today, right off the shelf, to eliminate redundant coding regardless of what technologies you support.