SAPUI5 Model Heirarchy

SAPUI5 Global Models

Global Models

Ever wonder why your SAPUI5 global model is empty? In today’s post explore global models and how they behave on different levels.

SAPUI5 Model Hierarchy

Below is an overview of the different levels of SAPUI5 models. Will drill-down from the global-level to low-level model as we go along.

SAPUI5 Model Heirarchy
SAPUI5 Model Hierarchy

Core Models

Core Models, sap.ui.getCore(), are the highest in the hierarchy. They sit on top of the launchpad for Fiori based or instance level of standalone, application.js or index.html, applications.

Launchpad Model
Launchpad Model

Typically, you can set the core model with the syntax below:

// set data
var oMyData = {
  test: 1
// create model instance
var oModel = new sap.ui.model.json.JSONModel(oMyData)
// set the core
sap.ui.getCore().setModel(oModel, 'myGlobalModel')

and access the core model via:

var oModel = sap.ui.getCore().getModel('myGlobalModel')

Models registered in this way make data accessible throughout the launchpad application, but, there’s a catch!

Since sap.ui.getCore() sits on the highest level of access in SAPUI5, this not only makes the data accessible to your application or component, but it also exposes the data to other components.

Furthermore, this does not mean components will inherit the models explicitly, but it will be accessible via the sap.ui.getCore().getModel method.

Let’s try an experiment.

We’ll declare a sap.ui.getCore() while we are on our launchpad.

Launchpad Model
Launchpad Model

Then, we’ll try to access the same model on our component level.

Core on Component Model
Core on Component Model

Let’s also check the component model, if the core model is propagated.

Component Model
Component Model

We saw that the core model is not propagated automatically, but still can be accessed via the sap.ui.getCore().getModel method.

Component Models

Next in the hierarchy are component models, these are commonly declared in the app descriptor (manifest.json) or component.js.

Component models are automatically propagated to child controls, unlike core models. This means any descendants will have access to its parent’s model (component) by default.

Components are forced to be self-contained and not dependent on core models.

Let’s try another experiment.

We’ll declare a component model in our component.js. And set the component model name to device.

In the example above, we can see that we can access the component model in the controller. Now let’s try to investigate if the component model is propagated to its descendant, which is the view in this case.

In the image above, we can see that the view didn’t inherit any model at all. There’s no propagated model on, nor data on oModels. But why?!

Parent controls are only referenced after the onInit event.

Since we accessed the component models during onInit we’ll get null values. Let’s try accessing the model during onRouteMatched.

The view now has access to our model. Accessing the propagated model with the code below will produce the same results.


Control Models

Last, in the hierarchy are control models. These types of models are fairly straightforward in terms of scope.

But do take note of the following:

  • Use control (views, pages, panels) models for any model not needed elsewhere.
  • Control models inherit component models.
  • Inherited models are only accessible after parent controls are referenced.
  • Do not use the sap.ui.getCore() for component-based applications as much as possible to prevent conflict.

In conclusion, it is very important to know where to declare and when to use a specific level of models in SAPUI5. This prevents data scope creep and prevents data conflict with other controls. In short, don’t pollute the global models as much as possible.

If you like this post, don’t forget to subscribe or get more SAPUI5 posts here.

Leave a Comment