SAPUI5 and Fiori Tools Part 3: Data Binding — JSON Model, OData Model, Modes

📌 KEY POINTS
✅ Binding connects controls to model data declaratively: {/path}, {model>/path}, {relativePath}.
✅ JSONModel for UI state; OData V4 model for backend data; ResourceModel for texts (i18n).
✅ Binding modes: one-way, two-way (default for V4 inputs), one-time.
💡 Use formatters and expression binding for display logic — not controller code.

▶ SAPUI5 DATA BINDING TUTORIAL: JSONMODEL, ODATA MODEL AND BINDING MODES

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHY BINDING MATTERS

Binding keeps UI controls connected to model data.

Instead of:

• reading a value;
• finding a control;
• setting the value;
• repeating this after every change;

you declare the relationship once.

━━━━━━━━━━━━━━━━━━━━
▶ 2. JSONMODEL

Use a JSON model for client-side state or small local datasets.

Example:

┏━━ CODE ━━━━━━━━━━━━
┃ const oModel = new JSONModel({
┃ customer: {
┃ name: "ABC Industries",
┃ status: "Active"
┃ }
┃ });
┃ this.getView().setModel(oModel);
┗━━━━━━━━━━━━━━━━━━━

View:

┏━━ CODE ━━━━━━━━━━━━
┃ <Text text="{/customer/name}" />
┗━━━━━━━━━━━━━━━━━━━

━━━━━━━━━━━━━━━━━━━━
▶ 3. NAMED MODELS

Use named models when different data concerns coexist.

Example:

• default OData model;
• "view" model for UI state;
• "i18n" resource model.

┏━━ CODE ━━━━━━━━━━━━
┃ <ObjectStatus text="{view>/statusText}" />
┗━━━━━━━━━━━━━━━━━━━

━━━━━━━━━━━━━━━━━━━━
▶ 4. BINDING CONTEXT

A control can inherit a context.

In a list, each row has a context pointing to one entity.

Use the binding context instead of relying on row indexes.

━━━━━━━━━━━━━━━━━━━━
▶ 5. ODATA MODEL

For backend business data, use the appropriate OData model for the service version.

Do not load the entire service into a JSON model just to make it feel simpler.

OData models provide server-side behavior such as filtering, paging and write handling.

━━━━━━━━━━━━━━━━━━━━
▶ 6. ONE-WAY VERSUS TWO-WAY

One-way binding:
model → UI

Two-way binding:
model ↔ UI

Use two-way only where user edits should update model state.

For read-only dashboards, one-way can be simpler.

━━━━━━━━━━━━━━━━━━━━
▶ 7. FORMATTERS

A formatter is useful for presentation logic.

Example:

┏━━ CODE ━━━━━━━━━━━━
┃ statusText: function (sStatus) {
┃ return sStatus === "A" ? "Active" : "Inactive";
┃ }
┗━━━━━━━━━━━━━━━━━━━

Do not put database/business rules into formatters.

━━━━━━━━━━━━━━━━━━━━
▶ 8. FILTERING AND SORTING

Prefer binding-level filters and sorters.

For large remote datasets, push filtering to the service rather than downloading thousands of rows.

━━━━━━━━━━━━━━━━━━━━
▶ CHECKPOINT

You should understand:

• model;
• binding path;
• named model;
• context;
• one-way/two-way;
• formatter;
• OData versus local JSON state.

━━━━━━━━━━━━━━━━━━━━
▶ INTERVIEW TAKEAWAY

“SAPUI5 data binding connects controls to model paths. I use JSONModel for local UI state and OData models for backend business data. I use binding contexts rather than row indexes, and I push filtering to the backend for large datasets.”

A table downloads 50,000 rows into a JSON model and filters them in the browser. Moving filtering/paging to the OData service dramatically reduces load time and memory.

• Huge remote datasets copied into JSONModel.
• Index-based row logic.
• Business rules inside formatter functions.
• Wrong binding mode.

• Use named models for clear concerns.
• Use contexts.
• Push large-data operations to backend.
• Keep formatter logic presentational.

Compare JSONModel and OData model. Explain binding context and why backend filtering matters.