Das Konzept

In SAP UI5 ist es möglich, bestehende Controls zu erweitern, sobald die normalen Funktionalitäten eines Controls nicht mehr ausreichen. Ebenso lassen sich ganz neue Controls erstellen, um den wachsenden Anforderungsschwierigkeiten gewachsen zu sein.

Leider weicht man jedoch dann vom Fiori-Standard ab und ist nicht mehr Guideline-Konform. Jedoch kann es trotzdem sein, dass man eine Aufgabenstellung zu bewältigen hat, die mit dem Standard nicht abzubilden ist.

Genau hier tritt das Custom-Control-Konzept ins Spiel.

 

Der Aufbau

Grundsätzlich ist ein UI5 Control nichts anderes als ein Modul, das zur Laufzeit dynamisch nachgeladen wird. Ein solches Modul wird mit sap.ui.define erstellt und kann anschließend angesprochen werden.

Des Weiteren wird ein UI5 Control immer als HTML-Element gerendered. Wie genau das aussieht, wird immer im Control-spezifischen render-Methode über den RenderManager definiert. Diese Methode wandelt das Custom Control in die HTML-Elemente um, wie es der Entwickler gerne haben möchte. So wird zum Beispiel beim Rendern einer sap.m.Table eine HTML-table mit td- und tr-Elementen in das DOM eingetragen und mit SAP-spezifischen CSS-Klassen gestyled.

Der Aufbau von Eigenschaften eines Controls wird immer in seinen Metadaten definiert. Ein Control hat ein dementsprechendes metadata-Object, wo Properties, Events, Aggregations und Associations definiert werden. Diese können dann in der View und über den Controller angesprochen werden.

Dies sieht wie folgt aus:

Sobald ich die Methode extend von dem sap.ui.core.Control aufrufe, erstelle ich ein neues Control. Wenn ich das extend von einem bestehenden Control aufrufen, z.B. dem sap.m.Button, würde ich dieses erweitern.

Nach dem ich nun ein neues Control erstellt habe, kann ich die Metadaten definieren:

 

Properties

Control-Properties bekommen ein Object zugewiesen, in dem ich den Datentyp zuweise und gegebenenfalls einen Default-Wert hinterlege.

Folgende Einstellungen kann ich also vornehmen:

  • type – Default type ist string.
  • defaultValue

Zulässige Datentypen für die type-Property sind:

  • string
  • int
  • float
  • string[]

Ich kann auch eigene Konfigurationsproperties innerhalb meiner Property erstellen und diese dann zur Datenverarbeitung nutzen.

Aggregations

Aggregations werden mit 3 verschiedenen Konfigurationen erstellt:

  • type – Default type ist sap.ui.core.Control.
  • multiple – Default ist true.
  • singularName
  • visibility 

Type gibt an, welches Control ich gerne aggrigieren möchte. Manchmal sind solche Aggregation-Controls nicht Module die von sap.ui.core.Control erben, sondern von der abstrakten Klasse sap.ui.core.Element. Sie haben daher keinen eigenen Renderer. Das Rendering von diesen Controls übernimmt das Control, das diese Elemente aggregiert. Mein Custom Control kann natürlich auch andere Custom Controls aggregieren.

Mit multiple: true kann ich sagen, ob meine Aggregation 0 bis N Controls aggregieren kann, oder ob nur ein Control in meiner Aggregation zugelassen wird.

Die Property singularName gibt einen String an, der für automatisch generierte Methoden eingefügt werden soll, um z.B. ein neues Item in die Items-Aggregation einzufügen.

Per visibility-Property lege ich fest, ob meine Aggregation in der View benutzt werden kann und ob sie für den Entwickler sichtbar sein sollte. Wenn die visibility auf Verbergen sein sollte, dann muss die Value „hidden“ vergeben werden.

Associations

Mit Associations können Controls miteinander verknüpft werden, bzw. es kann eine Abhängigkeit erstellt werden. Das bekannteste Beispiel ist die labelFor-Property/Association vom sap.m.Label.

Associations haben den gleichen Konfigurations-Aufbau wie Aggregations. Sie haben daher auch:

  • type
  • multiple
  • singularName
  • visibility

Events

Controls können Eventhandler für bestimmte HTML-Events definieren. Für jedes selbstdefinierte Event werden automasich folgende Funktionen erstellt:

  • attach<Name>
  • detach<Name>
  • fire<Name>

Somit würde ich z.B. für mein Custom Event saveForm die Funktionen attachSaveForm, detachSaveForm und fireSaveForm automatisch generiert bekommen.

Sobald ich ein Event erstellt habe, muss ich nur mehr den dementsprechenden HTML-Eventhandler definieren und dort die fire-Methode meines Events aufrufen. Für die Event-Handler-Implementierung erstelle ich innerhalb meines Controls eine neue Methode, die genau so heißt wie das dementsprechende HTML-Event.

Events können auch Parameter definieren, die ich bei einem fireEvent befülle.

myEvent: {

    parameters: { wasClicked: {type: „boolean“}}

}

Zusätze

Zusätzlich zu den 4 Basis-Konfigurationen stehen noch mehr Optionen zur Verfügung.

So kann ich

  • dnd – Drag and Drop
  • designtime – Design

zusätzlich definieren und konfigurieren. Auch kann ich das Metadaten-Objekt um eigene Einstellungen erweitern.

 

Coding

Die wichtigste Methode unseres Controls ist die onInit-Methode. Diese wird beim Initialisieren unseres Controls aufgerufen und dient mir als Startmöglichkeit.

Weitere Funktionen können ganz normal als Objekt-Methoden eingefügt werden. Hier sollte aber auf das Naming der Methoden geachtet werden, damit es keine Überschneidungen zu automatisch generierten Methoden kommt.

Mit Hilfe der automatisch generierten Set– und Get-Methoden meiner Properties kann ich jetzt auf diese zugreifen.

 

Render Manager

Nachdem ich nun die Metadaten und das Coding fertig habe, muss ich das Control auch dementsprechend anzeigen.

Hierfür dient der Render Manager in der renderer-Methode meines Controls. Mit dessen Hilfe kann ich in das DOM eingreifen und mein Control platzieren. Der Render Manager kommt in der renderer-Methode meines Controls zum Einsatz. Benutzt wird normaler HTML-Code, um unser Control in das DOM zu bringen.

Normalerweise wird die renderer-Methode in ein eigenes File ausgelagert.

Die wichtigsten Funktionen des RM’s sind:

  • openStart – Erstellt ein neues öffnendes Element <…
  • openEnd – Schließt das öffnende Element <…>
  • close – Schließt das Element </…>
  • write – Schreibt HTML-Code
  • writeControlData – Schreib die Conrol-ID in das DOM
  • renderControl – Ruft die renderer-Methode eines aggregierten Controls auf
  • class – Fügt eine CSS-Klasse dem HTML-Element hinzu
  • attr – Fügt dem Element ein Attribut mit Value hinzu

Zusammenfassung

Wir sehen, dass das Erstellen eines Custom-Controls einige Möglichkeiten beinhaltet. Wir können Properties, Aggregations, Events und Associations definieren. Zusätzlich benötigen wir noch die renderer-Methode mit dem RenderManager, um unser Control in das DOM zu bringen und anzuzeigen.

Im nächsten Blog-Part 2 werden wir ein Beispiel-Control entwickeln und uns im Detail die Implementierung ansehen.

Falls Fragen auftauchen, können sie gerne unten in den Kommentaren gestellt werden.  Ich freue mich auf Feedback.

Anmeldung zu unseremNewsletter

Anmeldung zu unseremNewsletter

Tragen Sie sich in unsere Mailingliste ein, um die neuesten Nachrichten und Updates von unserem Team zu erhalten.

Vielen Dank für die Anmeldung!