Changes
{{UBIK}} provides specific objects and tools for configuration and testing of the ACM environment and the result being published to the mobile client.
== How the ACM works ==
Technically, the ACM can be explained separating the following topics:
* Application and Context
* Scopes
* View and View Items
* Meta Definitions
=== Application and Context ===
An Application is used to identify Contexts. A Context is used to identify a View and all relevant Scopes. {{UBIK}} satellites use these two in order to identify the View that provides data for them, as well as the Scopes that decide what the data looks like. The Application's and Context's names have to be configured in the client's settings.
One could say the Context is the central object in every ACM configuration, connecting all the details.
=== Scopes ===
Scopes define what a {{UBIK}} object and its properties look like to a {{UBIK}} satellite. Let's say we have a pump with a lot of properties (that can be used for automatic data processing), but these properties aren't of much use to a human user. In this case, if I publish such pump objects to the user's mobile client (aka. {{UBIK}} satellite) via ACM, I probably want to give the user a more convenient, specialized version of these objects, containing only useful properties. With Scopes, one can define what an abstract content object should look like. One could say, they are post-processing filters for Meta Classes. Specifically, you can define which properties are visible, decide which classifications are published and configure rights (e.g. for writing a property value or creating instance objects for the Scope).
=== View and View Items ===
The View defines the hierarchical representation of all objects that should be available. The object's look & feel is described by Scopes, but the connection between those objects is described by the View. For example, if I have a root object ''Station A'' and as its child, I have an object ''Unit A.1'', then the View describes that ''Unit A.1'' is a child of ''Station A''.
Technically, the view uses View Items in order to describe the connection of objects. View Items are defined for a Meta Class, e.g. for the Meta Class ''Station'', and can provide the children for specific instances of such a Meta Class. In our example, if we have a View Item responsible for getting the Unit-children of a Station, for ''Station A'' (which is an instance of the scope ''Station'') it would retrieve ''Unit A.1''.
There are different types of View Items, depending on how the children should be resolved technically. The following types exist:
* Reference View Item (only 1 : N relations)
* Relation View Item (N : M relations possible)
* Query View Item (complex, custom child evaluation possible)
Reference View Items use a reference from each child to the parent in order to evaluate the children in a backward manner.
Relation View Items use relations from parents to children, where each parent can have multiple children and vice-versa, every child can have multiple parents.
Query View Items use a query to evaluate the children, but the parent object has to be the respective query object.
A View can have multiple view items for the same Meta Class (target type) in order to make a complex structure possible.
=== Meta Definitions ===
Last but not least, the {{UBIK}} satellites need to get Meta Definitions in order to interpret and use the content correctly. Meta Definitions describe (abstract) Meta Classes, Selective Lists, Units and rights as well as some information about the view structure, e.g. possible children of an element (in case the user wants to create a new object, like a picture for example).
The Meta Definitions are a result of the Scopes and the View for a specific Context. The customizer (you) has to publish these Meta Definitions actively though, using the [[ACM Manager]].
== Objects ==
