Advanced programming

collapse

#
- 1.) Application.config
- 2.) Basic concepts
  - 1.) Composite pattern
    - 1.) Lifecycle
    - 2.) Programming
  - 2.) Properties
    - 1.) Local
    - 2.) Network
    - 3.) Persistance
    - 4.) Configuration
    - 5.) Logging
  - 3.) Synchronous Methods
    - 1.) Virtual methods
  - 4.) References
    - 1.) 1 Object
    - 2.) N Objects locally
    - 3.) N Objects Network
  - 5.) Events
  - 6.) Asynchronous methods
  - 7.) Configuration
    - 1.) Config storage
    - 2.) Overriding
  - 8.) Messages and Alarms
    - 1.) Alarms
  - 9.) Database
    - 1.) Usage
    - 2.) Extend
      - 1.) EF 4.0
      - 2.) EF 7.0
    - 3.) Persistable queries
  - 10.) Designs
    - 1.) GUI Design
      - 1.) Set and convert Properties
      - 2.) Styles and Setter
      - 3.) Property trigger
      - 4.) Datatrigger
      - 5.) Events & trigger
      - 6.) Animations
      - 7.) Resources
    - 2.) Reports
      - 1.) Programming
  - 11.) Diagnose and Debugging
  - 12.) Updates
- 3.) UI-Controls
  - 1.) UI-Library integration
  - 2.) iPlus-Controls
  - 3.) Custom Controls
- 4.) Application programming
  - 1.) Multithreading
  - 2.) Businessobjects
    - 1.) Navigationless
    - 2.) Navigable
    - 3.) Context dependant dialogs
    - 4.) Background Tasks
  - 3.) Manager classes
  - 4.) Process applications
  - 5.) Workflow classes
  - 6.) External systems
    - 1.) Mobile devices
    - 2.) OPC UA Communication
      - 1.) Server
    - 3.) Simatic S7
  - 7.) Bit masking
- 5.) []

;

Introduction

The chapter 2.4. the configuration properties described use the configuration mechanism of iPlus. Basically, this is simply a table or an entity framework class with certain fields. The gip.core.datamodel.IACConfig interface defines which fields are required .

However, the configuration mechanism in iPlus is much more than just storing values of configuration variables. It solves the following problems:

A complex database model has a large number of tables that are linked together using foreign keys. Often you also need "M: N relations", which are shown in additional tables. In the case of large databases, these "M: N relations" can become very extensive and confusing. In practice, these relationships are often not needed at all and these tables are empty. It often only becomes clear during the project-specific implementation that additional relationships are required that were not thought of in advance. The result is that you have to expand the database model and thus also the entity framework model .
An application programmer often needs not only links between entity objects, but also between ACComponent instances. These can either be relationships within an application tree or more abstract relationships. eg for links between iPlus types (ACClass) from the application definition. Possibly. However, several objects must also be linked (e.g. an entity object from an application table with two instances from the application trees ...).
Workflows consist of a network of dynamic instances that are loaded and unloaded during runtime. These also require a configuration, which must be saved in advance and which is then read by the workflow nodes (also ACComponents) during instantiation or runtime. These are primarily the parameters of virtual methods (either from the workflow class itself or from function parameters for PAProcessFunctions). Also routing rules must be stored and read.
Business processes often hide many database tables that have to be read and processed in certain orders depending on the status. The further a business process has progressed, the more data that has been linked to one another and the more specific the information content. This is also the case with the configuration data - the further the process has progressed, the more configuration values have to be added but also previous ones have to be changed. We call this principle " strict separation of entities with increasing concretization " or technically speaking " overwriting of parameters ".

These problems are not solved by the IACConfig interface alone, but by a number of other interfaces:

These interfaces are already implemented in the "iPlus framework" as well as in "iPlus-MES" and the functionality can be used in the specific classes. You only need this if you want to develop your own data model with configuration options.

In the following sections, the existing implementation in iPlus is discussed in more detail.

Cookie settings