Skip to content

UI5 Binding Paths

Jump to bottom
Marco Beier edited this page Jun 22, 2020 · 8 revisions

Overview

Binding paths address the different properties and lists in a model and define how a node in the hierarchical data tree can be found. A binding path consists of a number of name tokens, which are separated by a separator char. In all models provided by the framework, the separator char is the slash '/'.

A binding path can either be absolute or relative: Absolute binding paths start with a slash, relative binding paths start with a name token and are resolved relative to the context of the control that is bound. A context exists either for each entry of the aggregation in case of aggregation binding or can be set explicitly for a control by using the setBindingContext method.

Whenever you're using more than one model, specify the model name within the binding path in order to address the correct model. The same applies for setting a binding context for such a model. The binding path must start with the model name followed by a '>'.

Setting a binding Context

//setting Context
oControl.setBindingContext(oContext);
//setting Context with an explicit model name
oControl.setBindingContext(oContext,"myModelName");

Binding with Path

'/Products/0/ProductName'
'/Products(0)/ProductName'
'ProductName'

//with model name
'myModelName>/Products/0/ProductName'
'myModelName>/Products(0)/ProductName'
'myModelName>ProductName'

bindElement vs BindingContext

someObject.setBindingContext(new sap.ui.model.Context(oModel, "/Path"));

The difference between those two is conceptual. The Binding Context is used as a parent context for all bindings (for that model) in that Control or its children. It only holds a reference to the used model, (a part of) the path and optional another parent context. It is used when creating relative bindings.

The bindElement method on the other hand behaves like every other bind* method. It creates a binding (in this case, a ContextBinding) which allows change events, data binding, etc. Additionally the created ContextBinding also serves as a BindingContext for other bindings, just like a Context added with setBindingContext would do.

Reading the code for ManagedObject might help to understand the internals better. (bindObject = bindElement)

Resource Model

The binding path syntax for the resource model only contains a flat list of properties.

  • Resource bundle content:

    CLOSE_BUTTON_TEXT=Close
OPEN_BUTTON_TEXT=Open
CANCEL_BUTTON_TEXT=Cancel

  • Binding paths within the model:

    CLOSE_BUTTON_TEXT
OPEN_BUTTON_TEXT
CANCEL_BUTTON_TEXT

More about the Resource Model here.

JSON Model

The JSON model has a simple binding path syntax, because it consists of named objects, such as properties, arrays, or nested objects.

Note: The correct JSON notation uses double quotes for the keys and string values.

{
    "company": {
        "name": "Treefish Inc",
        "info": {
            "employees": 3,
        },
        "contacts": [
            {
                "name": "Barbara",
                "phone": "873"
            },
            {
                "name": "Gerry",
                "phone": "734"
            },
            {
                "name": "Susan",
                "phone": "275"
            }
        ]
    }
}

Absolute binding path within the model

'/company/name'
'/company/info/employees'
'/company/contacts'

Relative binding path within the "/company" context

'name'
'info/employees'
'contacts'

Relative binding path within an aggregation binding of "/company/contacts"

'name'
'phone'

More about the JSON Model here.

XML Model

XML models differentiate between attributes and content. XML has no arrays and defines lists as multiple elements with the same name instead. This makes the binding path syntax for XML models more difficult than for JSON or OData models.

For attributes, a special selector using the "@" character exists and "text()" can be used to reference the content text of an element. Lists are referenced by using the path to the multiple element.

Note: For the XML model the root must not be included in the path.

<companies>
  <company name="Treefish Inc">
    <info>
       <employees>3</employees>
    </info>
    <contact phone="873">Barbara</contact>
    <contact phone="734">Gerry</contact>
    <contact phone="275">Susan</contact>
  </company>
</companies>

Absolute binding paths within this model

/company/@name
/company/info/employees

Relative binding paths within the "/company" context

@name
info/employees/text()

Relative binding paths within an aggregation binding of "/company/contact"

text()
@phone

  • Note:

    In a similar JSON model you would use /companies/company/locations as binding path for the locations collection. In an XML model the respective collection binding path is: /company/locations/location.

More about the XML Model here.

OData Model

The OData Model enables binding of controls to data from OData services.

The OData model is a server-side model, meaning that the data set is only available on the server and the client only knows the currently visible (requested) data. Operations, such as sorting and filtering, are done on the server. The client sends a request to the server and shows the returned data.

The OData model is probably the model which undergoes the most changes and improvements over time so I encourage to read up on the various documentations available about the current version of the used OData model.

More about the Odata Model here.

Credits

I really like the definition & explanation of the standard documentation therefore I decided to 1:1 copy them. This gives myself a better and faster overview whenever I need it.

Disclaimer

I do not claim to have everything written completely by myself. For more information check the credits section underneath the respective wiki pages.

Clone this wiki locally