Aggregation in SAP UI5

Question

Can anybody explain what exactly Aggregation means in SAP UI5 ? I am trying to make an app with two views and i want to navigate from one view to another and vice -versa.

Answer 1

Basic definition of «aggregation» from Glossary:

An aggregation (in the context of UI5) is a special relation between two UI element types. It is used to define the parent-child relationship [...]. The parent end of the aggregation has cardinality 0..1, while the child end may have 0..1 or 0..*.

For example, a list may have 0 or many items. An item has 0 or 1 list as its parent. Therefore, the list has an aggregation of «items».

---

In our case, the control sap.m.App, which is extended from sap.m.NavContainer, has a default aggregation named «pages» where we can define a collection of anything extended from sap.ui.core.Control as its child controls.

pages: sap.ui.core.Control [ ]

But just adding the views manually into <pages></pages> is an anti-pattern since a view has usually a Page in it and a single page takes up 100% of the height which pushes other views away. Besides that, it makes implementing navigation much more difficult.

Instead, the current best practice is to use a so-called «router» which is usually defined in the application descriptor (manifest.json) with other navigation properties. Its sister control Target takes care of adding the navigated view to the «pages» aggregation. To find out how to achieve navigation using a router, take a look at these resources:

• Examples: Basic navigation, navigation inside a static parent control
• «Routing and Navigation» from Walkthrough (see also further steps)
• «Routing and Navigation» from Essentials to understand the basic concepts.

Answer 2

This question is a little too broad for SO and you did not really investigate before by e.g. reading the documentation. Hence the downvotes.

Nevertheless, I will link you to the appropriate documentation page and provide a short excerpt and explication:

Controls can aggregate other controls. These controls with aggregations serve as a container or layout control to which the application can add child controls. They can also serve as composite controls if the control itself adds child controls and reuses available components. In an aggregation, child controls are owned by the parent control and are destroyed together with the parent control. A control can only have one aggregation parent. Adding the control to another aggregation removes it from the previous parent control.

In a nutshell, aggregations in UI5 have mostly the same meaning as a typical OOP aggregation: they represent has-a or conversely a is-a-part-of relationship between controls. Tables have rows, rows have cells and so on. The lifecycles of the related controls are bound (when the parent is destroyed, the children are also destroyed).

When looking strictly at aggregations, a UI5 application consists of a tree of controls, where the controls of one level are part of an aggregation of a control from the level above.

Each aggregation has its own semantics. For example the items of a sa.m.Table are displayed between the header and the footer and the pages of a NavContainer are displayed one at a time. The behavior of the aggregation contents is generally described in the SDK reference.