Introduction

Configuration resources are localizable strings and images used by the application to display information to the user.

The application resources are places in the packages and bound to the base schema in the schema hierarchy. When resources of a certain schema are queried, all resources are gathered throughout the hierarchy, after which a flat list of the gathered resources is generated.

Resources displayed as a hierarchy

There are two modes of displaying schema resources: design mode (Design-time) and application runtime mode (Run-time).

Design-time mode

This mode is used to display resources in designers and wizards. Schema resources are displayed only up to the package that contains the schema. Package resources that are not part of the hierarchy are not taken into account. For example, the ChildSchema schema (Fig. 1) will have the following resources:

• BaseResource: BaseValue;
• ChildResource: ChildValue.

The resources of the PackageWithReplacedResource1 and PackageWithReplacedResource2 packages that are not a part of the hierarchy are not taken into account. The resources in the PackageWithReplacedChildResource1 and PackageWithReplacedChildResource2 packages that are lower that the requested schema in the hierarchy are not taken into account as well.

Fig. 1 An example of the package hierarchy

If a schema is requested along with the package from which all resources must be obtained, then the resulting set of resources will be generated up to the level of the requested package. For example, ChildSchema schema resources up to the BottomPackage level will be as follows:

• BaseResource: BaseValue;
• ChildResource: ReplacedChildValue2;
• ChildResource1: Value1;
• ChildResource2: Value2.

The value of the ChildResource here has been changed to ReplacedChildValue2. This occurred because it has been replaced in the packages one level lower (Level 2). Packages with higher position value take precedence. If the position values are the same, the first package (if sorted by name) will take precedence.

Run-time mode

This mode displays resources in all system sections except for designers. The mechanism for obtaining resources is similar to the mechanism used in the Design-time mode. The main difference is that when a schema is requested, the resulting list will contain resources from packages that are not directly a part of the hierarchy. For example, if the ChildSchema resources are requested, the result will be as follows:

• BaseResource: ReplacedBaseValue2;
• Resource1: Value1;
• Resource2: Value2;
• ChildResource: ReplacedChildValue2;
• ChildResource1: Value1;
• ChildResource2: Value2.

Default resource view

If there are no resource values that can be displayed for users for a non-default culture, then the values are “reverted” to the default culture values.

This mechanism is implemented in the Terrasoft.Common.LocalizableString (displays a localized string) and Terrasoft.Common.LocalizableImage (displays a localized image) classes. These classes contain the following properties and methods for obtaining localized values:

• Value – a property that returns the value of a localized object for the current culture or the default culture, if the former is not found.
• HasValue – a property that returns the flag indicating that the value of a localized object exists for the current culture or the default culture, if the former is not found.
• GetCultureValue() – a method that returns the value of a localized object for the current culture or the default culture, if the former is not found.
• HasCultureValue() – a method that returns he flag indicating that the value of a localized object exists for the current culture.

Storing resources

Resources needed for the application operation are stored in the database. Resources can be stored in a version control system for installing on a new application or transferring between applications.

Storing resources in the database

The resources for each string or image are stored in the SysLocalizableValue database table in the “key-value” format. The table structure is available in table 1. Each record in the SysLocalizableValue table is bound to a package and an Id of the base Id schema. The schema itself can be located in a different package.

Table 1. SysLocalizableValue table structure

Column name	Description
Id	Table record Id
CreatedOn	Table record creation date
CreatedById	Link to the Contact who created the record.
ModifiedOn	Table record last modification date
ModifiedById	Link to the last Contact who edited the record.
SysPackageId	Link to the package (SysPackage).
SysSchemaId	Link to the base schema (SysSchema). This column is filled in for configuration resources only.
ResourceManager	Name of the resource manager. This column is filled in for core resources only.
SysCultureId	Link to the culture (SysCulture).
ResourceType	The type of resource.
IsChanged	Indicates whether the resource has been modified by the user.
Key	Resource key.
Value	Value of the string resource.
ImageData	Value of the image resource.

Default resource saving

If a resource is created by a user whose culture is not default, a record matching the user’s culture will be created for the resource. Newly created resources are automatically duplicated in the default culture. As a result, a similar resource record will be created with a link to the default culture. The new value of the resource will be displayed in all cultures if they don’t have a native value for that resource (please see the “Default resource view” section of this article).

Storing resources in the version control system and file system

The resource structure in the version control system and file system is covered in the "Resource storage structure” of the "Localizable resource structure and use” article.