Although every application has its own unique requirements, the individual components of applications are often very similar.

For example, menus, pop-up windows, and data entry forms and displays are common components of most applications. Pop-up windows, for instance, can vary in size, location and contents, but the commands to present them to the application user and to process the result of user interaction are essentially the same.

While Zim provides a great deal of flexibility in how applications can be designed and developed, experienced Zim programmers typically develop a programming style for various components of their applications. Consistency of style means that the application program code for one application object can be copied and modified when another, similar object is needed.

If a new pop-up window is needed, for example, the object definition and processing code for a similar, existing pop-up can be copied, and the necessary minor changes made. This approach can reduce development time considerably.

Template Definition

The template feature for Zim is a formal mechanism for producing reusable program code.

A template is an application program that contains the basic code for defining, presenting, and processing an application component such as a standard pop-up window. In addition, the template contains fragments of code that

• customize the basic code

• generate the application objects (e.g., windows, forms, variables) needed by the application components

Template Syntax

A template is similar to any other application program, in that it contains a series of command statements. However, a template is also different, in that it contains sections of code bounded by special template delimiters: << and >>.

The template delimiters are always placed at the start of a line; nothing else should appear on the same line. In this example,

… commands 1 …
<<
… commands 2 …
>>
… commands 3 …

the software handles the command statements that appear between the template delimiters differently depending on if the program is being executed, parsed, or compiled, or if it is being run under the GENERATE command.

During normal execution, commands 1 and commands 3 execute normally. Commands 2 are ignored.

With the PARSE or COMPILE command, commands 1 and commands 3 are parsed or compiles in the usual manner. Commands 2 are ignored.

With the GENERATE command, commands 1 and commands 3 execute normally. Commands 2 are sent as output, after macro substitution, to the current output device.

Program Call Syntax

The syntax of the call to the template program in the GENERATE command is identical to the structure of a call to a standard application program of the same type.

The rules for passing values to the parameters in a template program containing a formal procedure operate in exactly the same way as for an application program containing a formal procedure.

Program Execution

Program execution is handled slightly differently under GENERATE. Execution always proceeds interpretively, even if the template program has been compiled.

When the software encounters the << template delimiter alone on a line, execution is suspended, and the subsequent lines are written – after macro substitutions – to the current output destination. Execution resumes when the software encounters the >> template delimiter alone on a line.

Physical Line Handling

Normally, each physical line in the template is sent as a separate line to the current output destination.

To cause successive physical lines in the template to be joined into one line in the output, end the appropriate lines in the template with the dollar sign ($). At the output destination, the physical line containing the dollar sign and the next physical line appear concatenated on one physical line.

If a line must end with a dollar sign for another reason, direct the software to interpret the dollar sign literally by placing a backslash ( – Escape) preceding the dollar sign.