JeeWiz Architect's Guide - AtomicType Object


	The Model-Driven System Builder

JeeWiz Architect's Guide

Contents > 14. 'Business Object' Reference

14.4 AtomicType Object

Description An atomic type is defined by a modeler to represent a variation on a base type; the base type is either a logical datatype or another 'atomic-type'. The "logical types" we're referring to are the logical types in the JeeWiz generation system; (Meta-programmers: the logical datatypes are defined in $C.LDT in resources/bizobject/control/start.vm.)

The logical types are defined by meta-programmers; atomic types are defined by modelers.

The idea then is that the atomic-type can be used for the types of fields (in classes) and parameters (in methods) and be verified by the modeling tool. There is also a subsidiary benefit: that there does not need to be a change to the datatypes defined in the modelling tool (e.g. the <> in RSA/RSM). If the modelling tool has the ability to reference other models, a library of atomic types can be built up in one model and re-used in others.

Note: there is no ideal word to name this concept. We considered "data-type, user-type, restricted-type, primitive-type, logical-type". All these other names have their problems ... 'atomic-type' is the best, though imperfect, compromise.

For example:

you can use atomic types simply to rename types, such as the following which allows modellers to use "Boolean" as an alias for the logical type "boolean".

you can add restrictions on other types by specifying various constraints.

Here is a simple example of a stock number ('SKU') which must consist of 3 letters followed by 4 digits, separated by '/'

Here is a phone number type, which also shows the use of a filter-expression, with the use of ${name} to represent the eventual variable value:

The modeler can define the relationship to the base type in three ways:

by specifying the 'type' field. This should be the name of a logical type (string, boolean, int, etc.)

by modeling a generalisation relationship between the specialised class to the base class. This is converted by the XMI-JeeWiz XML transform into an 'extends' property.

the default if 'type' and 'extends' are not specified is 'string'.
The implication of the above is that in XML, an element can have a 'type' or 'extends' XML attribute, but not both.

The atomic-type information defined here will be represented in the modeling tool as a 'atomicType' stereotype on a class. (The profile creation tool converts '-t' in 'atomic-type' to 'T'.) The modeler defines a new atomic-type by creating a class stereotyped as <>.

Validation The 'extends' attribute must name an atomic type

Inherited
properties

template (base property)

text (base property)

jwpattern (base property)

14.4.1	Property 'name'
14.4.2	Property 'type'
14.4.3	Property 'extends'
14.4.4	Property 'description'
14.4.5	Property 'default'
14.4.6	Property 'filterExpression'

14.4.1 Property 'name'

*Description*	Specifies the name for the atomic type. This must follow the rules for identifiers (start with a letter or '_', not include '.' etc.). be distinct from the names for other atomic types - regardless of the package that the modeled element is in. In other words, you could try to define two atomic types 'myPackage.myAtomicType' and 'myOtherPackage.myAtomicType'. This is valid from the point as far as a modeling too is concerned, but it is not valid for the JeeWiz generation. be distinct from the names for logical types. This will also be caught by the validation in the JeeWiz generation. As of JeeWiz version 5.0, an atomic type cannot be an array, so do not put [] after the name.
*Type*	String
*Required*	true

14.4.2 Property 'type'

*Description*	Specifies the logical type that this atomic type restricts. This cannot be specified if the 'extends' property is also specified. If neither 'extends' nor 'type' properties are specified, the default type is 'string'. (Meta-programmers: more specifically, the empty or null entry in ${C.LDT}. This is the "string" logical atomic type in the standard JeeWiz generation systems.)
*Type*	String

14.4.3 Property 'extends'

*Description*	Specifies the base atomic type that this atomic type restricts. This must be the name of another atomic type. An atomic type cannot extend itself, either directly or indirectly. This cannot be specified if the 'type' property is also specified.
*Type*	String

14.4.4 Property 'description'

*Description*	Optional description of the atomic-type and its business relevance.
*Type*	String

14.4.5 Property 'default'

Description

Specifies a default value to which the field will be set when created.

This is an expression which should be compatible with the field's 'type', or the generated program will not compile. For primitive types, this will typically be just the literal value of the default, although it can be an expression. Note that you should just specify the value part for numeric values, not a type-defining suffix. For example, you must specify "0" rather that "0L".

For non-string objects, the default should create an object - e.g. 'new Integer(8)'.

String defaults are assumed to be string literals less the surrounding "". They will have double-quotes added automatically, so the default is a String constant - e.g. Fred goes into the code as "Fred".

You can alter this action, to specify expressions for string defaults, by prefixing the expression with '\', which will be stripped off. You can also start and end the default string value with '"', in which case it will not be altered.

String examples:

input: Fred code: "Fred"

input: \otherfield.substring(1) code: otherfield.substring(1)

input: \"" code: ""

The default expression as processed by the above algorithm can be retrieved via the method getDefaultExpression().

Type

String

14.4.6 Property 'filterExpression'

Description

This property gives an expression to filter incoming string values to be set into a property (i.e. field, attribute). This allows minor pre-processing of values before validation checks are made.

Note that this feature can only be used on properties whose logical data type is 'string'. The expression should use a variable to represent the property and evaluate to a string value representing the filtered value. There are three cases for the variable name to use:

for a normal property with a name (i.e. an entity attribute or named data-view-field), then the name to use is the property name
for a data-view-field with no name, then the name of the related attribute should be used
for an atomic type, the name to use is "${name}", which will be rendered into the name of the property that uses the atomic type.

For example, to remove white-space from an attribute named 'f' in Java, the filter-expression would be "f.trim()".

( If multiple languages are to be targetted, which is not supported in V5 renderings of JeeWiz... This expression is resolved for the language type, so if you are writing dual Java/C#, you could specify "f.${lang.String.trim}()". This will result in "f.trim()" in Java and "f.Trim()" in C#. )

The exact sequence of events surrounding the use of this field is:

The 'set' method is called with the unfiltered value with a parameter named after the field.
The method checks for non-null (and handles null values separately).
The parameter is filtered, by evaluating the filter-expression.
Validation checks are applied, using the result from the filter-expression.
The new value is set into the local property.

If the system has multiple tiers that use this value - for example, it is used both in screens and data-views - the filter expression will be used twice. This means that the filter-expression itself should return the same value if used on an already-filtered expression. Expressions that remove extraneous characters - as does the trim() method - meet this requirement; expressions that reorder or add extra values without checking the format of the existing value will not.

If a filter-expression is placed on an atomic type, then it is possible to have multiple filter-expressions evaluated at run-time. In this case, the filter-expression from the atomic type is applied before the filter-expression from the property.

Additional helper methods should be added into the JeeWizUtils. For example, see JeeWizUtils.removeChars().

Type

String