Da Binding mein absolutes Lieblingsthema ist wird sich dieser Beitrag auch wieder mit diesem Thema beschäftigen. Denn, mal Hand auf’s Herz, ohne die aus dem gebundenen Model geladenen Daten ist das schönste Gerüst nur eben das – ein Gerüst.
Im Speziellen geht es um das Binding im XML und wie dort durch unterschiedliche Parameter Einfluss auf die geladenen Daten genommen werden kann.

Konkret geht es um die Möglichkeit, bei Aggregation Bindings direkt sorter, filter und expand Parameter mitzugeben. Dies sind die, wie ich in der Praxis festgestellt habe, für eine produktive Anwendung relevantesten Parameter bei einem Binding.

Ein einfaches Beispiel

Ein einfaches Beispiel für ein Aggregation-Binding ist das Binden der Aggregation items einer Table (sap.m.Table). Ein Template kann in diesem Fall ein ColumnListItem sein.
Das normale Binding sieht wie folgt aus:

<Table
  items="{modelPersons>/ContactSet}">
  <columns>
    <Column />
  </columns>
  <items>
    <ColumnListItem>
      <Text text="{modelPersons>Name1}">
  </items>
</Table>

Kurz zum Verständnis: Wir haben ein benanntes oData-Model namens “modelPersons” und nutzen für das Aggregation-Binding das EntitySet “ContactSet”.

Das ist doch schon mal ein guter Anfang. Wir bekommen den Namen einer Person angezeigt. Beziehungsweise, da wir es ja mit einem Aggregation-Binding zu tun haben, die Namen ganz vieler Personen.

Und wie geht es jetzt weiter?

Nun, das war natürlich nur der Anfang.
Wir sehen schon was, aber reicht uns das?

Was, wenn ich noch mehr Daten anzeigen möchte?
Was, wenn man nicht alle Personen angezeigt haben möchte?
Was, wenn ich eine andere Reihenfolge haben möchte?

Meiner Erfahrung nach sind das, so oder so ähnlich, die zentralen Anforderungen, vor die man gestellt wird, wenn man es mit Aggregation Bindings zu tun hat.
Konkret möchte ich uns jetzt vor folgende Herausforderungen stellen:
–> Sortiere absteigend nach dem Namen!
–> Zeige nur ganz bestimmte “Meiers” an!
–> Zeige die Adresse einer Person mit an!

Und los! Äääh… aber wie jetzt genau?
Nun, dafür bedarf es erst mal der Parameter, die wir benutzen wollen.

Parameter

sorter
  Sortierung der Einträge aus dem Model

  path: Feld, nach dem wir sortieren möchten
  descending: Boolean-Angabe, ob wir absteigend sortieren möchten 
    (Aufsteigend wäre dann folgerichtig "descending = false")

filters
  Filterung der Einträge aus dem Model

  path: Feld, nach dem wir Filtern möchten
  operator: Eine Auflistung der Filter-Operatoren findet ihr hier
  value1: Wert, nach dem wir Filtern möchten
  value2: Manche Operatoren brauchen zwei Werte (z.B. BT)

expand
  Erweiterung des Models mit Daten aus zugehörigen Navigations

Sorter

Die erste Anforderung betrifft das Sortieren unserer Tabelle nach dem Namen.

<Table
  items="{
    path: 'modelPersons>/ContactSet',
    sorter: {
      path : 'Name1',
      descending: true
    }
  }" >
  <columns>
    <Column />
  </columns>
  <items>
    <ColumnListItem>
      <Label text="{modelPersons>Name1}" />
    </ColumnListItem>
  </items>
</Table>

Der Sorter ist im Binding des items mit integriert. Wir geben das Feld (Name1) und die Sortier-Richtung (descending = true) an.
Sobald wir Parameter in das Binding integrieren müssen wir unser gebundenes Array mit “{path: ”}” angeben. (In unserem Beispiel also: path:’modelPersons>/ContactSet’)

Filter

Die zweite Anforderung beinhaltete die Filterung nach ganz bestimmten “Meiers”.
Die Implementierung ist wie folgt:

<Table
  items="{
    path: 'modelPersons>/ContactSet',
    filters : [
      {path : 'Name1', operator : 'Contains', value1 : 'ei'},
      {path : 'Name1', operator : 'NE', value1 : 'Maier'},
      {path : 'Name1', operator : 'NE', value1 : 'Mayer'},
      {path : 'Name1', operator : 'NE', value1 : 'Meyer'}
    ]
  }" >
  <columns>
    <Column />
  </columns>
  <items>
    <ColumnListItem>
      <Label text="{modelPersons>Name1}" />
    </ColumnListItem>
  </items>
</Table>

Was im Gegensatz zum Sorter auffällt ist, dass filters ein Array ist. Heißt also, bei diesem Paramater können wir mehrere Filter mitgeben. Die Default-Verknüpfung der Filter ist hier “or”.
Um auf unser Beispiel zurückzukommen wird hier nach allen Kontakten mit einem “ei” im Namen gefiltert, schließt aber die Maier, Mayer und Meyer’s aus.
Über die Sinnhaftigkeit dieser Filterung lässt sich streiten, die Syntax sollte aber durch das Beispiel klar werden.

Expand

Beim expand geht es darum seine Entitäten mit zusätzlichen Informationen zu erweitern. Diese gehören nicht direkt zur Entität, haben aber eine direkte Verbindung (Navigation), weshalb sie dazu geladen werden können.
In unserem Beispiel möchten wir einem Kontakt seine Adressdaten mitgeben. Dazu benutzen wir ein expand auf die Verbindung “ToAddress”

<Table
  items="{
    path: 'modelPersons>/ContactSet',
    parameters : {
      expand : 'ToAddress'
    }
  }" >
  <columns>
    <Column />
    <Column />
  </columns>
  <items>
    <ColumnListItem>
      <Label text="{modelPersons>/name1}" />
      <Label text="{modelPersons>/ToAddress/street} 
        {modelPersons>/ToAddress/streetNumber}" />
    </ColumnListItem>
  </items>
</Table>

Kombination der verschiedenen Parameter

Die unterschiedlichen Kombinationen lassen sich natürlich auch kombinieren. Unser komplettes Beispiel sieht wie folgt aus:

<Table
  items="{
    path: 'modelPersons>/ContactSet',
    filters : [
      {path : 'Name1', operator : 'Contains', value1 : 'ei'},
      {path : 'Name1', operator : 'NE', value1 : 'Maier'},
      {path : 'Name1', operator : 'NE', value1 : 'Mayer'},
      {path : 'Name1', operator : 'NE', value1 : 'Meyer'}
    ],
    sorter: {
      path : 'Name1',
      descending: true
    },
    parameters : {
      expand : 'ToAddress'
    }
  }" >
  <columns>
    <Column />
    <Column />
  </columns>
  <items>
    <ColumnListItem>
      <Label text="{modelPersons>/name1}" />
      <Label text="{modelPersons>/ToAddress/street} 
        {modelPersons>/ToAddress/streetNumber}" />
    </ColumnListItem>
  </items>
</Table>

Fazit

Meiner Meinung nach stellen die Parameter im Binding im XML eine elegante, entwicklerische Lösung dar um direkt Einfluss auf das Binding zu nehmen. Der Code ist minimal und auch die Backend-Calls werden so minimiert, da die Parameter beim initialen Laden der Daten mitgegeben werden. Dies lässt sich ganz einfach im Network-Trace nachvollziehen.
Sobald die Syntax einmal geläufig ist, sollte die Implementierung, zumindest im Frontend, auch keine Probleme mehr bereiten.

Bis dahin erstmal und: “Kiek mol wedder in!”

Du interessierst dich für Fiori und hast Lust coole Projekte mit uns zu machen? Wir suchen dich! Schau doch mal in unserer Stellenbeschreibung vorbei.