Entwicklung ·Usability

Validierungen in Fiori Teil 2

Mach es bitte richtig – und schnell

In meinem vorherigen Beitrag habe ich die Validierung in Fiori auf Basis der API der Controls gezeigt. Ich habe im Controller die Werte der Eingaben evaluiert und ggf. Fehlertexte und Fehlerstatus gesetzt. Es hat gut funktioniert, aber rechtfertigen solche – eigentlich trivialen Prüfungen für eine Postleitzahl – 17 Zeilen JavaScript? Wie schon angedeutet, bietet das UI5-Framework hier weitere Möglichkeiten, die ich im vorherigen Post bewusst ausgelassen habe. Was ich in diesem Beitrag machen werde ist meine vorherige Lösung zu refactoren mittels sap.m.InputType und dem so genannten Data Binding Type System.

Beispiel Postleitzahl – revisited

Jetzt drehe ich mal die Zeit etwas zurück. Ich bin erneut beim Kunden und bespreche die Anforderungen bezüglich der Benutzerfreundlichkeit der neuen Fiori. Wie gehabt, hat der Kunde folgende Anforderungen für die Eingabe einer Postleitzahl:

  • Es dürfen nur Zahlen eingegeben werden
  • Es müssen genau fünf Stellen eingegeben werden
  • Der Anwender eine spezifische Fehlermeldung am Eingabefeld erhalten

Als Erstes möchte ich mich der Anforderung „Es dürfen nur Zahlen eingegeben werden“ zuwenden. Zur Erinnerung noch mal das Eingabefeld aus dem vorherigen Beitrag:

<Input
  value="{ path: 'Zipcode' }"
  change="onZipcodeChange"/>

Nach etwas Recherche ist mir wieder eingefallen, dass sap.m.Input Controls einen so genannten InputType haben können. InputType steuert in erster Linie das Verhalten des Eingabefeldes und wurde insbesondere mit den Anforderungen zur Vereinfachung von Eingaben für mobilen Anwendung konzipiert. Dies sind beispielsweise Eingaben von E-Mails, URLs, Passwörter oder Telefonnummern. Für mich interessant ist der Typ „Number“. Dieser Typ verhindert die Eingabe von Werten, die keiner Zahl entsprechen. Ferner würde sich auf einem Smartphone die „Tastatur“ reduzieren. So ein InputType das war genau das, was ich brauche. Das Feld für die Postleitzahl bekommt in der View den Typ „Number“.

<Input
  value="{ path: 'Zipcode' }"
  change="onZipcodeChange"
  type="Number"/>

nur_zahlen_plz
Der Effekt ist nun der, dass nur noch Zahlen als Eingabe (und, zugegeben, ein paar Sonderzeichen) erlaubt werden. Da ich nun die Kontrolle nach Zahlen vom Typ abgenommen bekommen habe, kann ich meine onZipcodeChange() im Controller entsprechend kürzen.

onZipcodeChange: function(oEvent){
  var oInput = oEvent.getSource();
  var sValue = oInput.getValue();
  var sErrorText = "";
  var sState = "None";

  if (sValue.length !== 5) {
    oInput.setValueState("Error");
    oInput.setValueStateText("Postleitzahl muss genau 5 Stellen lang sein. ");
  } else if (!sValue.match(/\d{5}/)) {
    sState = "Error";
    sErrorText = "Bitte geben Sie nur Zahlen ein.";
  }

  oInput.setValueState(sState);
  oInput.setValueStateText(sErrorText);
},

Der nächste Schritt des Refactoring ermöglicht sogar eine noch größere Reduktion vom selbstentwickelten JavaScript-Anteil. Das Data Binding Type System ist ein meiner Meinung nach kriminell unterkommuniziertes Feature von SAPUI5. Im Falle eines Data Binding, und das liegt ja in der Regel vor, können mittels dem Type System (nicht zu verwechseln mit dem Type-Attribut des sap.m.Input Control 😉 ) eine Reihe von automatischen Validierungen konfiguriert werden. Ein guter Einstieg in das Thema ist hier. Im Grunde ermöglicht das Type System Folgendes:

  • Properties eines Controls können zu archetypischen Datentypen (Datum, Ganzzahl, Zeichenkette, etc.) gemacht werden.
  • In der View lassen sich diverse Validierungsregeln (Constraints) für das Control festlegen.
  • Steuerung der Eigenschaften und das Verhalten des Eingefeldes, z.B. für ein gewisses Datumsformat.

Obwohl ich in meinem Postleitzahlenfeld nur Zahlen eingeben möchte, würde ein Feld vom Typ „sap.ui.model.type.Integer“ keine führenden Nullen erlauben. Nach etwas Recherche zeigte sich „String“ am passendsten für meinen Fall. Die möglichen Contraints für diesen Typ können hier  gefunden werden. In meinem Fall verwende ich die Contraints für die minimale und maximale Länge, die ich einfach auf jeweils 5 gelegt habe. Leider findet man die meisten Beispiele nur in JavaScript, aber so sehen Type und die beiden Constraints in einer XML-View aus:

<Input 
  type="Number" 
  value="{ path: 'Zipcode',
           type : 'sap.ui.model.type.String',
           constraints : {
             minLength : 5,
	     maxLength : 5
	   }
	}"
  change="onZipcodeChange"
/>

Automatisch greift nun die Form von Validierung auf genau 5 Zeichen, die ich zuvor in einem function() implementieren musste.
constraint_4constraint_6
Zwar ist die Fehlermeldung nun weniger explizit wie die selber geschriebene Meldung, aber immer noch verständlich genug. Das ermöglicht weiteres Refactoring an der Programmierung.

onZipcodeChange: function(oEvent){
  var oInput = oEvent.getSource();
  var sValue = oInput.getValue();

  if (sValue.length !== 5) {
    oInput.setValueState("Error");
    oInput.setValueStateText("Postleitzahl muss genau 5 Stellen lang sein. ");
  } 
},

Die onZipcodeChange() kann komplett entfernt werden.

<Input 
  type="Number" 
  value="{ path: 'Zipcode',
           type : 'sap.ui.model.type.String',
           constraints : {
             minLength : 5,
	     maxLength : 5
	   }
	}"
  change="onZipcodeChange"
/>

Ebenfalls wird nun das change-Event in der View nicht mehr benötigt.

Dank der Kombination aus dem sap.m.InputType und dem sap.ui.model.type.String konnte ich die Anforderungen des Kunden schnell, verlässlich und nur mit ein paar wenigen Zeilen XML-Definitionen erreichen. Hier war ich schon ziemlich zufrieden. Jedoch, und das ist jetzt ein Brückenschlag aus dem ersten und kommen Beitrag, stand noch die Validierung der komplexen Personalnummer im Haus. Welche Möglichkeiten das UI5-Framework für diese die Validierung komplexer Eingaben bietet, zeige ich Euch im nächsten Blog.

 

Schreibe einen Kommentar