JeeWiz Architect's Guide


	The Model-Driven System Builder

JeeWiz Architect's Guide

Contents > 10. JeeWiz Controls

10.1 Overview

10.1.1	The Devil Is In The Details
10.1.2	Design Alternatives To Controls
10.1.3	Previous Version Controls

10.1.1 The Devil Is In The Details

Some of the features discussed previously - templates and patternds - are all about large-scale architectual issues, i.e. how to render complete classes, groups of classes and their configuration.

There is another importance aspect of system generation, namely the detail level - words or parts of them, or phrases. These details are just as much determined by the technology or a customer's desires as the architectural level, so they need the same easy variability.

For example, to initialise a Java variable to a 'nothing' value you will have to say
$type $name = null;

for an object reference or, for a boolean:
$type $name = false;

The first implementation of code generation in this situation goes something like this:
#if( $type == "boolean" ) $type $name = false; #elseif( $type == "int" etc... ) $type $name = 0; #else $type $name = null; #end

The main problem with this is that this riff has to be repeated time and again. There is also a lost opportunity: Java and C# are so similar, you can get close to generating cross-platform code with a more general solution.

JeeWiz controls allow you to generate the 'null' or 'false', or '0' values without resorting to the Velocity #if statement. You do this by accessing a property (or method) of a control - using standard Velocity syntax - which returns the appropriate value for inclusion in the rendering. In the following example, '$dtc' is a data-type control:
$type $name = $dtc.nullValue;

There will be different controls for the different data-types available in the language - boolean, String etc. An attribute on a model object will typically have its type name validated and then mapped to a data-type control instance. JeeWiz allows us to store extra variables (that are not predefined in a meta-model), so the common approach is to use the 'dtc' property of the model object. For example:
#foreach( $attribute in $attributeList ) #set( $attribute.dtc = ## dtclookup( $attribute.type ) ## ) #if( !$attribute.dtc ) ... attribute type is invalid #end ... later ... $attribute.type $attribute.name = $attribute.dtc.nullValue;

The above example is fairly simple and the benefit of using controls may seem small- although maintenance is dramatically eased. The benefits are much greater in complex renderings, such as screen navigation, where the variabilities of datatypes, visual controls, data manipulation and navigation must all be done in the same template or pattern. Without using controls, these patterns would become unworkably complex.

Another benefit is that controls allow you to extend or modify the behaviour of scripts without touching the scripts themselves. Controls are much smaller and simpler than the scripts that use them so it makes sense to modify controls rather than the underlying scripts.

Probably the crucial benefit is that you can extend the functionality of a pattern or template without changing it, in ways that weren't originally anticipated by using special controls appropriate for the local environment.

10.1.2 Design Alternatives To Controls

As implied above, the first approach in implementing a rendering is to write '#if' statements. This requires no superstructure and is quick.

The next approach, to factor standard sequences in the rendering, is to create a Velocity macro or method. This approach does make overriding possible: the override macro or method can be put into a specific template directory, which is pulled in depending on the configuration being generated. It also means that the main template or pattern can be part of a standard product; a customisation team can change the effect of the generation process by adding customised macros/methods.

However, macros are not convenient when

there is state involved - we want to reference some external object, but macros are stateless.
there are multiple outputs required - we will need to build a range of macros, not just one or two.
there may be additions or changes in the future - we must plan for easy expansion, which is not possible with macros, because the names are fixed.

Any of these situations indicate that JeeWiz controls are a better approach, despite the extra investment in structure required. JeeWiz controls can

hold state - they are individual instances of Java classes
produce any number of outputs - 'outputs' are implemented just like JavaBean properties, as methods on Java classes
be enhanced or changed using the standard JeeWiz overriding techniques. New controls can be added by architects and referenced in models; existing controls can have particular outputs changed by overriding properties and methods.

10.1.3 Previous Version Controls

Previous versions of JeeWiz had a different structure and organisation of controls. This type of control is not documented here although it is still supported because the SOPERA product uses old-style controls (and JeeWiz V4).