RAP - Position der Buttons
In diesem Artikel schauen wir uns die verschiedenen Positionen der Buttons an. Wo können wir in RAP die verschiedenen Actions platzieren und wie nutzen wir diese.
Inhaltsverzeichnis
In diesem Artikel werden wir an verschiedenen Stellen im UI-Aktionen implementieren und uns die Möglichkeiten und Positionen anschauen.
Einleitung
Aktuell haben wir vor allem Aktionen auf Ebene der Tabelle im List Report definiert, doch es gibt auch noch Möglichkeiten, um eine Aktion einzublenden und unserem Anwender zur Verfügung zu stellen. Daher werden wir in diesem Artikel unsere Sales App um verschiedene Aktionen auf verschiedenen Ebenen erweitern.
Vorarbeit
Bevor wir mit dem eigentlichen Beispiel beginnen, deaktivieren wir im ersten Schritt die Analytical Table, die wir zu Demonstrationszwecken beim letzten Mal aktiviert hatten. Da wir aktuell alle Features unserer Anwendung wieder nutzen wollen, wechseln wir zur Responsive Table, dem Standard es List Reports. Dazu entfernen wir aus dem Projection View ZBS_C_SASale alle Informationen zur Aggregation.
Verhaltensdefinition
Um die Actions im nächsten Schritt referenzieren zu können, legen wir uns in der Verhaltensdefinition ZBS_R_SASale die verschiedenen Aktionen an und implementieren die leeren Hüllen.
Suchhilfe
Zuerst einmal definieren wir eine Suchhilfe, die wir gleich für zwei abstrakte Entitäten benötigen. Dabei handelt es sich um eine einfache Suchhilfe über den Partner, so wie wir sie bereits für das Material umgesetzt haben.
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Partner Value Help'
@Search.searchable: true
define view entity ZBS_I_SAPartnerVH
as select from zbs_dmo_partner
{
@Search.defaultSearchElement: true
@Search.fuzzinessThreshold: 1.0
@ObjectModel.text.element: [ 'Name' ]
@UI.textArrangement: #TEXT_LAST
key partner as Partner,
@Search.defaultSearchElement: true
@Search.fuzzinessThreshold: 0.8
name as Name
}
Abstrakte Entitäten
Definieren wir uns im zweiten Schritt zwei abstrakte Entitäten, die wir später zur Eingabe für zwei der neuen Aktionen benötigen. Dabei wollen wir Factory Actions definieren, die zuvor einige Daten abfragen. Zuerst einmal die Entität zur Befüllung der Festwertabweichung.
@EndUserText.label: 'Fix Value Create Action'
define abstract entity ZBS_S_SAPopupFixValue
{
@Consumption.valueHelpDefinition: [{ entity: { name: 'ZBS_I_SAPartnerVH', element : 'Partner' } }]
@EndUserText.label : 'Partner'
PartnerNumber : zbs_demo_sa_partner;
@EndUserText.label : 'Sales Date'
SalesDate : zbs_demo_sa_date;
@Semantics.amount.currencyCode: 'DifferenceCurrency'
@EndUserText.label : 'Amount'
DifferenceAmount : zbs_demo_sa_amount;
@EndUserText.label : 'Currency'
DifferenceCurrency : zbs_demo_sa_currency;
}
Die zweite Entität ist zur Eingabe einer prozentualen Abweichung. Die ersten beiden Felder sind gleich, doch dann haben wir andere Felder für die Eingabe.
@EndUserText.label: 'Percent Create Action'
define abstract entity ZBS_S_SAPopupPercent
{
@Consumption.valueHelpDefinition: [{ entity: { name: 'ZBS_I_SAPartnerVH', element : 'Partner' } }]
@EndUserText.label : 'Partner'
PartnerNumber : zbs_demo_sa_partner;
@EndUserText.label : 'Sales Date'
SalesDate : zbs_demo_sa_date;
@Semantics.quantity.unitOfMeasure : 'DifferenceUnit'
@EndUserText.label : 'Quantity'
DifferenceQuantity : zbs_demo_sa_quantity;
@EndUserText.label : 'Unit'
DifferenceUnit : zbs_demo_sa_unit;
}
Definition
Insgesamt definieren wir 5 Aktionen. Die ersten 4 Aktionen definieren wir auf der ROOT Ebene in der Entität ZBS_R_SASale. Hier definieren wir zwei Factory Actions mit Eingabeparametern, eine Aktion für eine Konsistenzprüfung des Objekts und eine Prüfung, um die Differenzen zu löschen.
static factory action ( authorization : global ) createFixValue parameter ZBS_S_SAPopupFixValue [1];
static factory action ( authorization : global ) createPercent parameter ZBS_S_SAPopupPercent [1];
action ConsistencyCheck;
action ClearDifferences;
In der Entität ZBS_I_SASold definieren wir noch eine Aktion, um die Freigabe der Positionen in der Entität auszulösen. Diese definieren wir als normale Instanzaktion.
action ReleaseItems;
Implementierung
Die Implementierung der leeren Hüllen, legen wir per Quick Fix (STRG + 1) an und formatieren die Klasse. Die Implementierung würden wir in diesem Artikel nicht durchführen.
Projection
Damit die Aktionen auch später in unserer App funktionieren, müssen wir sie noch in der Projection des RAP Objekts freigeben. Per USE ACTION werden die verschiedenen Aktionen nach außen verfügbar gemacht. Das Gleiche auch auf Ebene der fünften Aktion machen, diese haben wir aus diesem Beispiel gelassen, findest du aber im GitHub Repository.
use action createFixValue;
use action createPercent;
use action ConsistencyCheck;
use action ClearDifferences;
Aktion - Liste
Die einfachste und am meisten genutzte Aktion wird im List Report direkt an der Tabelle definiert. Dort können statische Actions, Factory Actions und normale Actions definiert werden. Die normale Aktion benötigt immer markierte Elemente in der Liste, die anderen Beiden sind statisch und benötigen keine Referenz. Die Aktion wird am "UI.lineItem" definiert, hier kannst du dir das zu implementierende Objekt (Feld) aussuchen, dass spielt soweit keine Rolle. "Position" bestimmt die Reihenfolge, wie die Buttons eingeblendet werden.
@UI.lineItem: [
{ position: 10, type: #FOR_ACTION, dataAction: 'createFixValue', label: 'Create Fix Value' },
{ position: 20, type: #FOR_ACTION, dataAction: 'createPercent', label: 'Create Percent' }
]
Die beiden Aktionen werden nun im List Report über der Tabelle angezeigt und stehen dort vor CREATE und DELETE. Da sie STATIC sind, sind sie auch ohne markierten Eintrag ausführbar und von Beginn an aktiv.
Führen wir eine der Aktionen aus, dann wird auch entsprechend eine Eingabe angezeigt.
Aktion - Object Page
Definieren wir im nächsten Schritt die Aktion auf der Object Page im oberen Bereich direkt neben dem EDIT und DELETE Button. Dazu verwenden wir anstatt dem LineItem nun "UI.identification". Damit wir der Button von der Liste auf die Object Page verschoben.
@UI.identification: [
{ position: 10, type: #FOR_ACTION, dataAction: 'ConsistencyCheck', label: 'Check consistency' }
]
Die Aktion ist verfügbar und aktiv. Hierbei handelt es sich aber nicht um eine statische Aktion, sondern diese ist an eine Instanz gebunden, da wir uns aktuell in den Details unseres gewählten Objekts befinden. Anders als in der Liste, befinden sich unsere eigenen Aktionen hinter dem Standard.
Aktion - Bereich
Definieren wir im dritten Schritt eine Aktion direkt zwischen unseren Daten. Damit bekommen wir die eigentliche Aktion so nah wie möglich an den Bereich, auf den die Aktion Einfluss hat. Dabei stehen uns verschiedene Positionen zur Verfügung. Definieren wir einmal eine Aktion auf Ebene der Differenzen, hierbei verwenden wir wieder "UI.identification", allerdings geben wir den "qualifier" an, um die Aktion an einen Bereich zu hängen.
@UI.identification: [
{ position: 20, type: #FOR_ACTION, dataAction: 'ClearDifferences', label: 'Clear', qualifier: 'DIFF' }
]
Aktualisieren wir das UI, dann findest du die neue Aktion neben der Überschrift des Bereichs. Damit liegt sie außerhalb des eigentlichen Bereichs und ist recht gut zu sehen.
Ergänzen wir den Zusatz "inline", dann wird die Aktion in den Bereich übernommen, allerdings vergrößert sich dann auch der Abstand.
@UI.identification: [
{ position: 20, type: #FOR_ACTION, dataAction: 'ClearDifferences', label: 'Clear', qualifier: 'DIFF', inline: true }
]
Nach der Änderung wird die eigentliche Aktion im Bereich angezeigt. Je nach Platz auf dem UI, wird die Aktion anders eingebunden. Grundsätzlich kannst du die Aktion nicht nur an "identification" hängen, sondern auch an "fieldGroups". Da du in einem Bereich mehrere Gruppen definieren kannst, kannst du sie damit auch innerhalb eines Bereichs an verschiedene Positionen hängen.
Aktion - Subentität
Als letzten Schritt wiederholen wir die eigentliche Aktion und binden den neuen Button an eine Tabelle. In diesem Beispiel verwenden wir eine Subentität im Objekt und erzeugen damit einen Button auf der Object Page, an der eigentlichen Tabelle. Die Annotation ist identisch zum Schritt für die Liste, hier erweitern wir nur die Metadata Extension von ZBS_C_SASold.
@UI.lineItem: [
{ position: 10, type: #FOR_ACTION, dataAction: 'ReleaseItems', label: 'Release' }
]
Als Ergebnis erhalten wir den Button über der Tabelle auf der Object Page und können damit einzelne Items in der Tabelle freigeben.
Farbe
Grundsätzlich können wir einem Button auf dem UI auch eine Farbe geben. Dabei müssen wir hier mit dem Zusatz "criticality" arbeiten und verweisen dabei auf den Inhalt eines anderen Feldes. Dabei verwenden wir ein virtuelles Element, dass wir zuvor angelegt haben und welches wir aktuell mit 1 befüllen.
@UI.identification: [
{ position: 10, type: #FOR_ACTION, dataAction: 'ConsistencyCheck', label: 'Check consistency', criticality: 'ButtonCriticality' }
]
Als Ergebnis verändert sich die Farbe des Buttons in Rot, entsprechend der definierten Kritikalität. Weitere Informationen zu den möglichen Farben findest du unter diesem Link zu Fiori Elements.
Vollständiges Beispiel
Das vollständige Beispiel findest du in GitHub im entsprechenden Paket für die Sales App. Die Änderungen aus diesem Artikel findest du in diesem Commit und kannst damit die Änderungen, plus die Zusatzinformationen, nachvollziehen.
Fazit
Möchtest du in deiner Anwendung spezifische Aktionen zu spezifischen Bereichen erstellen, dann kannst du diese an die verschiedenen Bereiche im UI hängen. Über die zusätzlichen Gestaltungsmittel kannst du den User im UI einfacher führen und klarmachen, wofür die eigentliche Aktion gedacht ist.
