📄️ Storing Configuration Data
There are several ways to store configuration data (as opposed to process data) in Ignition, depending on what the data represents and how it is used. The majority of data will be stored in the Ignition Internal Database, an embedded database that is managed by the platform, though in special cases it is necessary to store data directly to disk.
📄️ Extension Points
The Extension Point system is a single, unified interface for extending various parts of the Ignition platform. Modules can provide new implementations of various abstract concepts with extension points. The Extension Point system is closely tied to the persistence and web interface system, reducing the amount of work required to expose and store configuration data.
📄️ Localization
Localization adapts an application to present information in a way consistent with what users in different countries are accustomed to, such as date formatting. Ignition supports localization. It is fairly easy for module developers to adapt their code to support it, though it is easier if they understand how the system works from the outset.
📄️ Redundancy
Ignition supports redundancy, in which two gateways share configuration, and only one is active at a given time. It is crucial that module developers consider early on in the development process how this affects their module.
📄️ Style and Naming Conventions
In general, the Ignition platform follows the recommendations of the Oracle Code Conventions for the Java Programming Language. Most of the interfaces and classes in the Ignition platform are named using the standard casing. Some items, however, have names that are products of their history, which may make them a bit confusing. The following list tries to identify inconsistent or legacy naming schemes that module writers are likely to encounter:
📄️ Module Services
Module services are a way for modules to provide APIs to other modules, or to implement well-known services in new ways. The ModuleSerivcesManager (accessed through GatewayContext) is a directory of Objects, referenced by their class type. Any module can register a new ModuleService, and other modules can subscribe to these types of services and retrieve the registered instance when its available. This allows child modules to get the running instance of a class provided by a parent module.