Program generation

If a decision table is correct and all mandatory sources are filled or the interface generation is used, then program code can be ge­ne­ra­ted.

Generating program code

The simplest way to start program code generation for an already opened decision table is to use the key combination CTRL+G (Save + Generate). This functions on all screens and starts saving the decision table with subsequent generation of the source file. An example here for Java:

01

02

If the generation variant Interface is not used, then it is imperative for successful generation that all "must" sources are filled (see also Preconditions and Programming). mis­sing "must" sources in newly inserted conditions or actions are often the cause of error messages du­ring generation.

Only if the interface generation is not used: In order to check the "look & feel" of the ge­ne­ra­ted program code in advance even without programming, the mis­sing mandatory source codes can be ge­ne­ra­ted most quickly via Generate Scrapbook followed by immediate Read Scrapbook. The automatically ge­ne­ra­ted source codes are only compilable "dummies" and must be replaced later by "real" statements.

Additional information:

More than one language

If more than one language is activated in a decision table, in this example the Java and C# languages, an expanded generation menu is displayed:

01

The language used most recently, in this case Java, is listed first and linked with the key combination CTRL+G. The scrapbook functions are also offered for this language.

Alternatively, generation for another language (in this case C#) or generation for all languages activated in this decision table can be selected from this menu.

Additional information:

The protocol screen

The individual generation steps appear on a protocol screen:

01

Click the OK button when you want to close the protocol screen. Otherwise, it automatically closes after 10 seconds. The screen does not close automatically if the user has ‘touched’ it, e.g. by clicking or moving the text area.

Optionally, you can save the whole screen as a file or copy it to the system clipboard.

If errors occur du­ring generation, these also appear on the protocol screen and the progress bar changes to red:

02

You can use the corresponding icons in the source code editor to jump directly to mis­sing source codes:

03

Jump to previous empty mandatory source code

04

Jump to next empty mandatory source code

The generated program code

By default, the ge­ne­ra­ted source code is stored in the file system in the folder containing the decision table. The name of the decision table is used as the file name. The respective extension depends on the language selected.

Optionally, the generation can also be adjusted to meet any project requirements:

  • Individual file names and/or extensions

  • Storage of the ge­ne­ra­ted source code in a different location.

  • Storage of the ge­ne­ra­ted source code in the system clipboard

  • Automatic start of own scripts for individual subsequent processing, e.g. file transfers, compilations, execution of test suites, etc.

Additional information:

Placeholders

Placeholders are characters or strings that will later be replaced with specific data in the source code. For LF‑ET, placeholders begin with "$$". The following placeholders are currently available:

Placeholder Meaning

$$Datn

The date of the generation timestamp in the numerical format YYYYMMDD.

$$DtName
$$EtName

The name of the decision table.

$$Footer

Decision table footers (these mark the end of the ge­ne­ra­ted source code).
If necessary, this placeholder can be used to move the comment ge­ne­ra­ted by default at the end of the source code to any position in the source code.

$$Header

Decision table headers with important information such as the generation date and time.
If necessary, this placeholder can be used to move the comment ge­ne­ra­ted by default at the start of the source code to any position in the source code.

$$LastRuleID

The highest rule ID in the decision table. It can also be regarded as the technical version number of the decision table.

$$Nr

Number of the condition or action.

$$OccNr

The number (position) of a condition value or action value in the values table. This makes it easier to program source codes for condition values or action values when they differ only by this one value:
Instead of:
       code for e.g. C01/01: (#STEP = 1)
       code for e.g. C01/02: (#STEP = 2)
       code for e.g. C01/03: (#STEP = 3)
you can now write or copy:
       code for e.g. C01/01: (#STEP = $$OccNr)
       code for e.g. C01/02: (#STEP = $$OccNr)
       code for e.g. C01/03: (#STEP = $$OccNr)
Thus, it is no longer necessary to modify the source codes when making changes (e.g. moving, deleting or copying values).

$$Rule

The rule number of the currently ge­ne­ra­ted rule, i.e. the number of the rule column, see also: Standard sorting.

$$Rules

The current count of rule columns in the decision table.

$$RuleID

The rule ID of the currently ge­ne­ra­ted rule together with the LastRuleID of the decision table, with the format: #nn.mm (nn=RuleID, mm=LastRuleID). The format facilitates later automatic statistical analyses.

$$Symbol

The symbol of condition or action values.

$$Timn

The time of the generation timestamp in the numerical format HHMMSS.

$$Title

The title of condition or action values

$$Version

The timestamp of the source code generation, with the date and time separated by a point, e.g.: 20140307.115613.
Alternatively, the save time stamp of a decision table can be used, ide.<Sprache>.baseOfVersion.

Upper case / lower case is irrelevant when using placeholders. When program code is ge­ne­ra­ted, the placeholders are replaced with the actual values at that time.

An example for Java: Generation of rule 5 of 10 for decision table “Test”:

Source code in DT ge­ne­ra­ted source code

System.out.println("$$EtName, $$Version, $$Rules, $$Rule");

System.out.println("Test, 20240721.115613, 10, 5");

Generation parameters

Generation parameters are program-language specific information, such as the setting of the file name and extension for the ge­ne­ra­ted source code.

  • You should add generation parameters as comment lines directly in the source code. We recommend using the first lines of the prolog to the decision table for this.

  • If you do not enter any generation parameters, the generation works with the default values.

  • It is possible to have more than one generation parameter in one line

  • Upper case / lower case is irrelevant

  • No generation parameter may occur more than once

  • After successful generation, the list of processed generation parameters can be viewed in the tooltip in the info line

  • If errors occur (invalid or mis­sing values, duplicate generation parameters, etc.), generation is interrupted and a detailed description of the reason for this is displayed to the user on the screen

Source transfer

With ‘open’ development environments, which manage software objects in the file system, special mechanisms for source transfer are generally unnecessary since LF‑ET objects in the file system can in any case be written and read without problems.

The situation is different with ‘closed’ development environments that manage the software object e.g. in databases: JDeveloper, SQL Developer, NetWeaver, Natural, etc.

For Natural, LF‑ET can, for example, automatically log into the development environment via an integrated NDV adapter and then save, compile and read the source code. As a more powerful alternative to complex adapters, LF‑ET can use a function of the operating system:

The system clipboard

With generation parameters in the configuration file Project.ini, you can activate and configure the automatic use of the system clipboard for a programming language:

ide.language.clipboard=true

This generation parameter activates the additional use of the system clipboard du­ring source generation and scrapbook import.

Effect du­ring generation:

First, the source file is ge­ne­ra­ted “completely normally”, then the source code is also automatically copied to the system clipboard. After you have switched to the editor in the development environment, the source code can be pasted directly there, e.g. using the key combination CTRL+V.

Effect du­ring import:

First, the system clipboard is checked. If it contains a ge­ne­ra­ted source code in the current language, that source code is imported from the system clipboard. Otherwise, the source file is found in the file system and imported from there.

ide.language.clipboard.encoding=…


Optionally, the system clipboard can be used to define an encoding for the IO that is different from the operating system encoding.

The encodings available in the system can be viewed using the menu bar under Help > Details > ap­pli­ca­tion info > LookAndFeel [nnn available encodings].

ide.language.clipboard.suppressFile=true


Optionally, you can use the system clipboard to prevent the source file from being saved in the file system.

To activate automatic use of the clipboard e.g. for ABAP, you have to specify the following parameters in the Project.ini configuration file.

ide.abap=true
ide.abap.clipboard=true

The first parameter is a so-called “base key”. It determines whether special settings should be considered for a particular language. All other parameter for this language are only analyzed if the “base key” is assigned the value true.

See also:

The LF‑ET Maven plugin

Especially for code generation with Maven an LF‑ET-Maven plugin is available, the latest version incl. documentation can always be downloaded here:

http://www.lohrfink.de/lfet/maven-plugin

LF‑ET is integrated in the Maven plugin, i.e. to use new generation options it may be necessary to update not only LF‑ET at the developer’s but also the plugin in the development environment in parallel.

Installation, configuration and usage is described in a PDF document included with the plugin.