Expansion Tokens
Expansion tokens are special symbols that can be used within a template file, either to cause CodeGen to take some special action, or to refer to some information from a metadata source. Most expansion tokens cause CodeGen to output some piece of information to the output stream for the current template. In some cases the information that is output is fairly generic, for example the current date or time, but in many cases the information is derived from an external source such as a repository structure. CodeGen recognizes and processes several different categories of expansion tokens. Some of these tokens can be used at any time, whilst others can only be used within a certain context in a template file.
Expansion tokens consist of a single tag (a special keyword delimited by less-than (<) and greater-than (>) characters) and most cause some value to be written to the output stream for the current template. An example of an expansion token of this type is the <DATE> token that was discussed earlier.
When CodeGen processes a template file in order to create an output file it is constantly searching for known expansion tokens, and when a token is encountered some action is taken based on the name and nature of the token.
|
Generic tokens are tokens which can be used in any template file. |
|
|
Structure tokens are tokens which are replaced with some piece of information obtained from, or some piece of code derived from a Repository structure. Structure tokens can only be used when processing a template in conjunction with a Repository structure. Processing a template file which uses one or more structure tokens without referencing a Repository structure will cause an error during code generation. |
|
|
Field loop tokens are tokens which are replaced with some piece of information obtained from, or some piece of code derived from a Repository field definition. Field loop tokens are only valid inside a field loop. This again implies that a Repository structure is required in order to process a template containing field loop tokens. Processing a template file which uses one or more field loop tokens without referencing a Repository structure will cause an error during code generation. |
|
|
Field loop expression tokens are tokens which allow you to control whether a certain piece of code is emitted to the output file or not, based on the evaluation of some expression based on the attributes of field. For example, you could use a conditional expression to only emit a piece of code if a field is marked as a required field, or if the data type of a field is decimal. |
|
|
Key loop tokens are tokens which are replaced with some piece of information obtained from, or some piece of code derived from a Repository key definition. Key loop tokens are only valid inside a key loop. |
|
|
Key segment loop tokens are tokens which are replaced with some piece of information obtained from, or some piece of code derived from a Repository key segment definition. Key segment loop tokens are only valid inside a key segment loop. |
|
|
Relation loop tokens are tokens which are replaced with some piece of information obtained from, or some piece of code derived from a Repository relation definition. Relation loop tokens are only valid inside a relation loop. |
|
|
Window tokens are tokens which are replaced with some piece of information about a window definition. |
|
|
Button loop tokens are tokens which are replaced with some piece of information relating to a button definition. Button loop tokens are only valid within a button loop. |
|
|
User defined tokens are non-standard tokens that can be defined by you in order to have CodeGen generate code other than what it natively supports. There are several ways of defining user defined tokens. User defined tokens do not inherently require the use of a Repository structure during code generation, unless the code generated by the user defined tokens includes other structure or field loop tokens. |
|
|
Loop utility tokens insert information based on the processing status of the current template file loop construct, and can be used in any of the loop constructs. |
Expansion Token Variations
All expansion tokens are valid in upper case (as shown in this documentation) and many are valid only in upper case. Generally, when the name of an expansion token appears in uppercase, then the associated replacement text that is written to the output stream will also be in upper case. But there are some exceptions to this rule, typically when the token refers to a piece of metadata which resolves to a piece of “free text” such as descriptions that were entered as free text.
Some tokens are documented to have "alternate forms". For example, the <STRUCTURE_NAME> token, which normally outputs the name of the repository structure in all uppercase characters, has five alternate forms, as follows:
Token Type |
Token |
Description |
Example |
|
Upper-case |
<STRUCTURE_NAME> |
This token causes the name of the current structure to be sent to the output file, in all uppercase, and with underscores preserved. |
CUSTOMER_CONTACT |
|
Lower-case |
<structure_name> |
This token causes the name of the current structure to be sent to the output file, in all lowercase, and with underscores preserved. |
customer_contact |
|
Mixed-case |
<Structure_Name> |
This token causes the name of the current structure to be sent to the output file, in lowercase, but with the first letter of each word upper-cased, and with underscores preserved. |
Customer_Contact |
|
"xf"-case |
<Structure_name> |
This token causes the name of the current structure to be sent to the output file, in lowercase, but with the first letter of the first word upper-cased, and with underscores preserved. This format is compatible with the way in which GENCS and GENJAVA expose Synergy data to xfNetLink clients. |
Customer_contact |
|
Pascal-case |
<StructureName> |
This token causes the name of the current structure to be sent to the output file in “pascal-case”. The string is lower-cased and then any character following anything except 0-9, A-Z and a-z is upper-cased. Then anything other than 0-9, A-Z and a-z is removed, and finally the first character is upper-cased. |
CustomerContact |
|
Camel-case |
<structureName> |
This token causes the name of the current structure to be sent to the output file in “camel-case”. The string is lower-cased and then any character following anything except 0-9, A-Z and a-z is upper-cased. Finally anything other than 0-9, A-Z and a-z is removed. |
customerContact |
If an expansion token is not documented to have alternate forms then that token is ONLY valid when typed in upper case. CodeGen will not act upon tokens that it does not recognize. Any token that CodeGen does not explicitly recognize will simply be ignored, and written to the output stream. If you see tokens in your output file, check your spelling and case sensitivity. The only exception to this rule is if you are using “user defined tokens” which are documented later.
Copyright © 2021 Synergex International, Inc.