Application Context Management - Revision history

NWE: /* View and View Items */

2016-12-15T15:47:42Z

‎View and View Items

NWE: /* Meta Definitions */

2016-12-15T15:33:33Z

‎Meta Definitions

NWE at 15:26, 15 December 2016

2016-12-15T15:26:34Z

NWE: /* See also */

2016-12-14T16:44:17Z

‎See also

KNO at 16:19, 2 February 2015

2015-02-02T16:19:43Z

KNO at 12:30, 30 January 2015

2015-01-30T12:30:44Z

KNO: /* See also */

2015-01-30T12:30:09Z

‎See also

KNO at 12:29, 30 January 2015

2015-01-30T12:29:57Z

KNO at 18:59, 11 December 2013

2013-12-11T18:59:20Z

KNO at 18:58, 11 December 2013

2013-12-11T18:58:07Z

@@ Line 21: / Line 21: @@
 === 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''.
+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 Meta Class ''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)
@@ Line 30: / Line 30: @@
 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 ===

@@ Line 33: / Line 33: @@
 === 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]].
+The Meta Definitions are a result of the Scopes and the View for a specific Context. The customizer has to publish these Meta Definitions actively though, using the [[ACM Manager]].
 == Objects ==

← Older revision		Revision as of 15:26, 15 December 2016
Line 4:		Line 4:

	{{UBIK}} provides specific objects and tools for configuration and testing of the ACM environment and the result being published to the mobile client.		{{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 ==		== Objects ==

@@ Line 35: / Line 35: @@
 * [[HowTo:Customize_Logo_%26_Background_on_Mobile_Client|Customize Logo & Background on Mobile Client]]
 * [[View Test Environment]]
-[[Category:Publishing]]
+[[Category:Publishing|Application Context Management]]

← Older revision		Revision as of 16:19, 2 February 2015
Line 36:		Line 36:
	* [[View Test Environment]]		* [[View Test Environment]]

−	[[Category:~~Application Context Management~~]]	+	[[Category:Publishing]]

@@ Line 1: / Line 1: @@
 The Application Context Management (ACM) represents the conceptual approach to configure the potential visualization and management of objects on the client. Objects, its properties and relations can be used to set up a user defined behavior including the creation of new objects, documents, etc. For each type of object its characteristics with respect to hierarchy and its properties can explicitly be managed by the user.
-Along with the object oriented configuration, the user might also [[Customize_Logo_%26_Background_on_Mobile_Client|customize the logo and background images]] for the mobile application to enhance the users' experience.
+Along with the object oriented configuration, the user might also [[HowTo:Customize_Logo_%26_Background_on_Mobile_Client|customize the logo and background images]] for the mobile application to enhance the users' experience.
 {{UBIK}} provides specific objects and tools for configuration and testing of the ACM environment and the result being published to the mobile client.

@@ Line 33: / Line 33: @@
 == See also ==
 * [[ACM Manager]]
-* [[Customize_Logo_%26_Background_on_Mobile_Client|Customize Logo & Background on Mobile Client]]
+* [[HowTo:Customize_Logo_%26_Background_on_Mobile_Client|Customize Logo & Background on Mobile Client]]
 * [[View Test Environment]]
 [[Category:Application Context Management]]

← Older revision		Revision as of 12:29, 30 January 2015
Line 36:		Line 36:
	* [[View Test Environment]]		* [[View Test Environment]]

−	[[Category:~~UBIK~~]]	+	[[Category:Application Context Management]]

← Older revision		Revision as of 18:59, 11 December 2013
Line 37:		Line 37:

	[[Category:UBIK]]		[[Category:UBIK]]
−	~~[[Category:Application Context Management]]~~

← Older revision		Revision as of 18:58, 11 December 2013
Line 37:		Line 37:

	[[Category:UBIK]]		[[Category:UBIK]]
		+	[[Category:Application Context Management]]