Contexts

As described previously, variables can be defined in various places within FirstSpirit. Precisely where a variable is to be defined depends on the requirements of the respective project and the application case.

Variables are available within FirstSpirit objects. Each FirstSpirit object has a so-called context. This context can be used to describe and influence the properties of the respective object. Depending on the type, a FirstSpirit object can contain other FirstSpirit objects, e.g. a page of the Page Store can contain sections, a section can contain other sections or data sets. In general, a new context is opened in an “external” object by means of an “internal” object. This brings about a hierarchical arrangement of the contexts. Each internal FirstSpirit object inherits the context information of the external objects.

A context only exists together with the object. Against the background of the generation, in which the individual FirstSpirit objects are evaluated and resolved in the order defined by the project, the objects have a certain life. The life of the context also ends when the life of an object ends; the context is "closed" again. The context data is then no longer available to objects on the same hierarchical level.

Variables are part of the context information and can therefore affect the behavior of the object. This also means that variables are transferred from external to internal objects by defect, and are also by default only available as long as the context or the object. If necessary they can, however, be placed in "higher" contexts so that their life is lengthened. The advantage of a variable that has a longer life is that it can be accessed in many places within the project, however, this also means that name conflicts are more likely.

In the following, the availability of variables within templates (separated from the project context) are described first, then the availability of variables project-wide. Finally, several special variable properties are described.