docs

Data Binding Tutorial

In this tutorial, we explain the concepts of data binding in OpenUI5.

This tutorial has been moved.

• For a JavaScript version, see JavaScript Data Binding Tutorial on GitHub.

• For a TypeScript version, see TypeScript Data Binding Tutorial on GitHub.

• Step 1: No Data Binding
  In this step, we create a basic application and simply place some text on the screen using a standard sap.m.Text control. The text in this control is a hard-coded part of the control’s definition; therefore, this is not an example of data binding!
• Step 2: Creating a Model
  In this step, we create a model. It serves as a container for the data your application operates on.
• Step 3: Create Property Binding
  Although there is no visible difference, the text on the screen is now derived from model data.
• Step 4: Two-Way Data Binding
  In the examples we’ve looked at so far, we’ve displayed the value of a model property using a read-only field. We’ll now change the user interface to display first and last name fields using sap.m.Input fields. We’re also adding a check box control to enable or disable both input fields. This setup illustrates a feature known as “two-way data binding”. As the view now contains more controls, we’re also moving the view definition into an XML file.
• Step 5: One-Way Data Binding
  Unlike the two-way binding behavior we’ve seen, one-way data binding is also possible. In this case, data travels in one direction only: from the model, through the binding instance, to the consumer (usually the property of a control), but never in the other direction. Let’s modify the previous example to use one-way data binding. This shows how you can switch off the flow of data from the user interface back to the model if needed.
• Step 6: Resource Models
  Business applications often require language-specific (translatable) text used as labels and descriptions on the user interface.
• Step 7: (Optional) Resource Bundles and Multiple Languages
  Resource bundles exist to enable an app to run in multiple languages without the need to change any code. To demonstrate this feature, let’s create a German version of the app – in fact, all we need to do is create a German version of the resource bundle file. In our code, we activate the German locale for the ResourceModel.
• Step 8: Binding Paths: Accessing Properties in Hierarchically Structured Models
  In Step 6 , we stated that the fields in a resource model are arranged in a flat structure; in other words, there is no hierarchy of properties. However, this is only true for resource models. The properties within JSON and OData models are usually arranged in a hierarchical structure. So, let’s explore how to reference fields in a hierarchically structured model object.
• Step 9: Formatting Values
  We’d also like to provide our users with a way of contacting Harry Hawk, so we’re adding a link that sends an e-mail to Harry. To do this, we convert our data in the model to match the sap.m.URLHelper.normalizeEmail API. As soon as the user changes the name, the e-mail also changes. We need a custom formatter function for this.
• Step 10: Property Formatting Using Data Types
  OpenUI5 offers a set of simple data types, including Boolean, Currency, Date and Float. You can apply these data types to controls to ensure that the value displayed on the screen is formatted correctly. If the field is open for input, this also ensures that the user input meets the requirements of that data type. Let’s add a new field called Sales Amount of type Currency.
• Step 11: Validation Using sap/ui/core/Messaging
  Up to this point, we’ve created a currency field that formats itself correctly. The currency data type can also validate user input to ensure it meets currency requirements. However, OpenUI5 manages data type validation functions and doesn’t have a built-in mechanism for reporting error messages back to the UI. We therefore need a way to report error messages from validation functions back to the user. In this step, we’re enabling validation for the entire app with a feature known as “Messaging”. Once this is set up, any validation error messages based on user input get passed to Messaging, which then connects them to the appropriate view and control that caused the error.
• Step 12: Aggregation Binding Using Templates
  Aggregation binding, also known as “list binding”, lets a control bind to a list within the model data. This binding allows relative binding to the list entries by its child controls.
• Step 13: Element Binding
  Now, let’s do something with that newly generated list. Typically, you use a list to allow selection of an item and then display the details of that item elsewhere. To accomplish this, we use a form with relatively bound controls and bind it to the selected entity via element binding.
• Step 14: Expression Binding
  An expression binding lets you display a calculated value on the screen, which is derived from values found in a model object. This feature allows you to insert simple formatting or calculations directly into the data binding string. In this example, we’re changing the color of the price depending on whether it’s above or below a certain threshold. The threshold value is stored in the JSON model.
• Step 15: Aggregation Binding Using a Factory Function
  Instead of using a single hard-coded template control, we now opt for a factory function to generate different controls based on the data received at runtime. This approach is much more flexible and allows for the display of complex or heterogeneous data.

Related Information

Data Binding

Use the MVC Concept

This site is open source. Improve this page.