|
|
|
The Model-Driven System Builder
|
|
JeeWiz Architect's Guide
|
|
|
|
Contents >
3. JeeWiz Input
|
|
|
3.1 Basics
3.1.1 Terminology - Assembly
|
In describing JeeWiz models, we use the term 'assembly', which mimics manufacturing terminology.
An assembly can be built up from sub-assemblies, and can then be used as a component in a higher-level assembly.
For example, an engine assembly will be built from piston and crankshaft sub-assemblies,
and then itself used as a sub-assembly in the whole car.
However, a piston ring or a crankshaft bearing is a simple component rather than an assembly
because it is manufactured individually rather than assembled from many components.
In the same way, JeeWiz builds software components in an extensible, recursive manufacturing process.
In this sense, the input model is the specification of an assembly
and sub-assemblies that are 'manufactured' have a build job (in our case, an Ant build) to do the manufacturing.
The 'top component' of a build is the root model object of the complete assembly.
There is a 'topComponents' property that specifies what the top component can be.
3.1.2 Locating the Input File
|
This section describes the usage of models comprising a single XML file representing a single input model;
the next section gives details about multi-file and multi-model inputs.
The location of a single input file is defined in one of two ways:
- By its directory.
In this case, the name of the input file must be 'assembly.xml'.
The default directory is the 'specification' subdirectory of the project directory.
For example, if the project directory is
jeewiz/examples/java/simple
|
then the default directory holding assembly.xml is
jeewiz/examples/java/simple/specification
|
The specification directory can be specified by the 'assemblyDir' property to the build job.
- By specifying the file path in the build property 'assemblyFile'.
This file can be anywhere, specified absolutely, or relative to the project directory.
The file path specified by 'assemblyFile' does not need to have a '.xml' extension.
By default - if no 'assemblyDir' or 'assemblyFile' build property is present -
the assembly directory of 'specification' is used,
and there must be (at least) a file named 'assembly.xml' in the specification subdirectory of the project.
3.1.3 XML Structure
|
JeeWiz directly processes XML elements, attributes and character data.
JeeWiz uses SAX to interpret the XML.
The XML must be well-formed (in particular, there must be a single root element) but it is not validated against a particular schema.
While the input XML can incorporate external entities, there is a special meta-factor feature built into JeeWiz that should be used instead.
Character data can be input as text between XML markup or as CDATA sections: they are treated the same.
Multiple character data blocks can be present for a given XML element;
these are aggregated into a single string in the order they appear.
3.1.4 Validation
|
Although JeeWiz does not use XML validation - for example against a DTD or XML Schema - it does provide validation using based on
meta-validator definitions that can hold Java expressions and code snippets.
Typical validations are that elements or properties are present,
that elements referenced by name properties in other elements do indeed exist, and so on.
If an input model does not meet the JeeWiz validation, processing terminates before any output is created.
Because patterns are run at different stage of the build,
the validation can be targetted at particular stages, just before each pattern phase is run.
More details of the timing of build stages is given here.
By default, JeeWiz allows unexpected XML elements, attributes and character data to be present in the input.
This information is made available to the rendering processors (Ant and Velocity) in the same way as items defined in the meta-models.
JeeWiz can also disallow unexpected XML elements, by setting the 'strictXMLReadIn' build property.
Copyright (c) 2001-2008 New Technology/enterprise Ltd.
| |
