Introduction

“To bind or not to bind, that is the question” is a quote you should very rarely be citing when working with SAPUI5. The reason for that is simple – it is easier to work with binding than it is without. In this week’s blog post, we will go through the ‘M’ of the MVC concept and show you why it is crucial to understand it from the start. This week, you will learn the basics about:

  • Models in SAPUI5
  • Data binding

Models in UI5

You have briefly interacted with models last week, remember? We used the i18n model to introduce translatable texts into our application. The idea is simple – model provides a container with the data and binding is a connector between the model and our view/controller. For i18n, we wrote ‘{i18n>title}’ to bind the title element to the ‘title’ property of the i18n model. As you can imagine, binding does not change when the language is changed. Instead, the data in the model is replaced. Models can also be direct connectors to the application backend. If programmed well, respective queries on the model will trigger a backend request which the developer does not need to worry about. You will see it later when we get to the backend part of the tutorial series.

Data binding in SAP

In simple terms, binding listens to changes on the model and automatically updates the value of the element when a change occurs. It is a seamless process that does not require any calls to update functions. You could almost think of binding as an invisible pointer which just points to the data in the corresponding model, instead of storing it on the element level. You will understand it more as we get deeper into the topic but for now, just think of it as a connector to the model.

Advantages of using binding

Right now, you might be asking yourself “why bother?”. There are a lot of advantages of using bindings, here are just a few:

  1. Less code – you do not need to call any update logic on the elements
  2. Consistency – if 2 or more elements are bound to the same path, there is less room for errors
  3. Scalability – if a requirement changes and you suddenly need to reuse the data, you have it all in one place
  4. Performance – the UI5 framework takes good care of the performance behind updates

SAPUI5 Data binding in practice

Let’s try to keep the theory short and sweet and instead, focus on some hands-on work. Open your WebIDE and follow along. Let me know in the comments section below, if things are unclear.

Exercise 1: Introducing binding to our app

We’ll begin by changing our existing application to use binding. This will hopefully prove to you, that binding is the way forward :)

To recap, the application we’ve created last week has 3 elements: Input, button and a label. Once the button is pressed, the inserted text gets rendered in the label with a small i18n-based addition. How can we convert it to use binding? Let’s see!

Creation of a new model

First, we need a model. We’ll create it in the webapp/model/models.js file

We do this by implementing a getDataModel function which creates an empty JSON model with inputText property set to blank.

This provides us with the model, but it still cannot be accessed because we haven’t assigned it to our application (the new function doesn’t get called). Next step, is to call the new function from within the onInit event of the controller and assign it to the view so it can be bound to.

We do this by calling the setModel function on the reference to the view. This supports 2 parameters: 1 – the model object and 2 – optional model name. I’m sure you have already noticed the way we are referencing the getDataModel function here. We use the Model variable that we had imported in the controller definition above (see lines 3 & 4).

Ok, now. How do we know that the model has been assigned? We can use the Chrome Developer tools for that.

Open our application and launch the Console (press F11), go to the ‘Sources’ tab and find the controller. Click on the line number representing one of the lines inside the onButtonPress function to set a breakpoint. Now, press the button in your app window. It should stop at them set breakpoint.

Now, go to the console and check the content of our view/controller

As you can see, our view now contains a model called localData, which contains the property inputText

Binding Label to the model

Ok, the next task is relatively simple, we will now bind the Label element to the newly created model. This will build a connection and ensure that the data we see on the screen is always in sync with the data contained in the inputText property of the newly created model. To do that, we introduce a new text property to the Label element. The property refers to the value printed on the screen. You can first try to hardcode it and refresh the app. You will see that the element now renders with the text you’ve hardcoded.

Now is the time to replace it with the binding path which points to the created model

To test this, we will give the property inputText created in the models.js file an initial value

If you now refresh the app, you will see that the label is loaded with an initial value coming from the model. Huraaay!

Binding Input to Label

To show you the real power of binding, we will do something bold… Let’s remove the button and it’s callback function “onButtonPress“. Now, let’s also clear the default value for inputText. The end result, after reloading the app should be just an input box in the middle of the screen.

We will now bind the input to the same binding path as the label, which in turn, should result in the label getting updated with the value that’s being typed into the input box. It’s actually quite simple :)

First, we need to add the value property to the input and bind it to the same path as the label’s text property.

You might be tempted to refresh the app and expect the input to be replicated into the label but it’s still just one step too early :)

Default Binding mode – One-way vs Two-way

The default behaviour of a model is that it displays the data (we see the data in the label element) but it does not update it when a bound element’s property makes an attempt to change it. This is called One-way binding. It is mainly used to ensure data consistency, when it’s required. We need to explicitly enable two-way updates by switching the binding mode to two-way.

Coming back to the above example, to make our new enhancement work, we need to add one line of code in the models.js file to enable the TwoWay binding mode

If you now reload the app, you will see that once you type something into the input and navigate outside using tab or click, the value of the label will refresh. To make it more ‘lively’ add another property to the Input – valueLiveUpdate=”true”. This will make it fully real-time :)

Summary

I decided to make this week’s tutorial short, you now have some time to play around with different use cases and implement binding in them. Next week, we will go through the different types of bindings, discuss binding paths in detail and build something a little bit more sophisticated.

In the meantime, as this week’s challenge, I dare you to build an application which contains:

  • Table of 4 columns and 2 rows
    • First row – 4 buttons
    • Second row – 4 label fields with some random text
  • Clicking the buttons should toggle the corresponding label’s visibility

Feel free to share your results in the comments! Don’t forget to sign up to the newsletter!

Next: Why Bind? – Part 2