Einleitung

Dieser Blog richtet sich an die Leserschaft, die bereits mit Angular vertraut sind, jedoch ihr Wissen über Forms vertiefen wollen. Wer über weniger Erfahrung verfügt, benutzt besser die detailliertere Schrit um Schritt Beschreibung mit den zur Verfügung gestellten Anwendungsbeispielen, welche hier zu finden sind.

 

Forms und Ihre Bedeutung

Views bzw. Forms übernehmen bei Web-Applikationen eine bedeutende Rolle. Sie verbinden Mensch und Maschine und sind dafür verantwortlich, dass deren Austausch von Informationen verständlich und fehlerfrei stattfindet. Die vom Benutzer eingegebenen Daten werden validiert und nur dann an die nächste Schicht übergeben, wenn sie fehlerfrei sind. Sind die Eingabedaten falsch, muss der Benutzer unmittelbar nach der Eingabe verständlich darüber informiert werden.

Typische Anforderungen an Forms sind zum Beispiel:

• Die Daten müssen gemäss den Anforderungen vollständig und gültig sein, bevor sie versendet werden.
• Eine möglichst genaue Beschreibung liefern, falls ein Fehler vorliegt. Eine Eingabe kann z.B. mehrere Fehlerursachen haben. z.B. dass eine Emailadresse nicht das gültige Muster einer Emailadresse aufweist, oder dass die eingetippte Emailadresse bei der Registrierung bereits verwendet wurde.
• Abhängigkeiten zwischen den Controls müssen modellierbar sein. Zum Beispiel stellt eine Dropdownbox nur die Auswahl-Elemente zur Verfügung, die sich nach dem gewählten Wert eines anderen Eingabefeldes orientieren.
• Regeln für das Anzeigen von Validierungsfehler befolgen. Soll z.B. während der Eingabe ein festgestellter Fehler angezeigt werden oder erst beim Sendeversuch der Daten? Soll der Sendebutton erst dann den Status «Enable» bekommen, wenn alle Daten gültig sind?)
• Sicherheitsaspekte erfüllen, damit Hacker keine Grundlage geschaffen wird, um in ein System einzudringen.
• Aspekte der Barrierefreiheit berücksichtigen.

 

Strategie der Validierung

Validierungsnachrichten  gleich nach der Eingabe anzeigen

Eingabedaten sollen unmittelbar nach ihrer Eingabe validiert und allfällige Eingabefehler dem Benutzer mitgeteilt werden. Nicht bediente Pflichtfelder oder fehlerhafte Felder sollen dazu führen, dass ein Formular nicht versendet wird. 

 

Der Button «Submit» kann durch den Benutzer erst dann betätigt werden, wenn die Daten gültig, vollständig und fehlerfrei sein.

 

Validierungsnachrichten erst beim Sendeversuch anzeigen

Oft werden bei Web-Applikationen Validierungsmitteilungen erst dann angezeigt, wenn der Sendebutton betätigt wird. Das trifft meistens dann zu, wenn die Daten serverseitig geprüft werden. Diese Strategie ist weniger benutzerfreundlich und sollte deshalb nicht angewendet werden.

Zeitpunkt der Validierungsnachrichten bestimmen

Wann der Validierungszeitpunkt stattfinden soll, kann über  die ngFormOptions bestimmt werden. Mehr dazu in den untenstehenden Kapiteln.

Technologien

Angular verfolgt zur Erstellung von Formularen zwei Techniken. Model-Driven (reaktiver Ansatz) oder Template-Driven:

Template-Driven

 Die Funtionsweise

 

Template-Driven benötigt das Model nicht, die Definitionen werden deklarativ im HTML vorgenommen. Dabei kommt das Forms-API zum Tragen, welches im Hauptmodul mittels FormsModule wie folgt importiert und registriert wird.

 

Dadurch wird die direktive NgForm erzeugt und kann wie im Beispiel der lokalen Variable «cutomerForm» zugewiesen werden. (Achtung, diese Variable ist nur innerhalb des Templates gültig).

Dies führt dazu, dass Properties bereitgestellt werden, die den Kontrollstatus und die Gültigkeit des Forms verfolgen. Folgende Properties und Methoden stehen zur Verfügung:

Properties Methode	Bedeutung
submitted	Gibt zurück, ob eine Form-Übermittlung ausgelöst wurde
errors	Gibt an, ob ein Form fehlerhaft ist. Tritt mindestens ein Fehler in einem Eingabefeld auf, hat die Variable den Wert «true»
touched	Gibt an, ob ein Eingabefeld den Fokus erhielt oder ein Mouse-Event ausgelöst wurde.
dirty	Wird ein Wert in einem Eingabefeld nach der Eingabe verändert, hat die Variable «dirty» den Wert true
resetForm()	Alle Eingabefelder werden zurückgesetzt.
controls	Gibt ein Instanz der FormControl aus der FormGroup zurück.

 

Folgendes Beispiel zeigt, wie die Properties von ngForm angewendet werden:

<button type="submit" class="btn btn-default" [disabled]="customerForm.invalid"> Senden </button> 1 2 3 4 <button type="submit" class="btn btn-default"      [disabled]="customerForm.invalid">      Senden </button>

Der Button «Senden” wird disabled dargestellt, falls das Formular fehlerhafte Daten hat. In diesem konkreten Fall wird das HTML-Property «disabled» an die Variable «customerForm.invalid» gebunden.  Eine Änderung dieses Variablenwertes wird somit gleich an dieses HTML-Property übertragen. Sobald das Formular valide ist, wird auch der Button enabled dargestellt. Dies geschieht über das One-Way-Binding.

Eine weitere Möglichkeit zur Validierung bieten Direktiven. Folgende wird hier für die Prüfung bereits registrierter Emailadressen verwendet

Der Einsatz von Direktiven für Validierungszwecke

und wird im Template wie folgt integriert.

In dieser Direktive wird ein Http-Service verwendet, damit in einem externen Server die Prüfung durchgeführt werden kann, ob eine Emailadresse für eine Registrierung bereits schon verwendet wurde.

Da die Anbindung über einen externen Server erfolgt, erhalten wir das Prüfergebnis asynchron und verwenden deshalb in der  Directive das NG_ASYNC_VALIDATORS-Token. Pipe bietet hier die Möglichkeiten, den Operator map auf die Werte des Streams anzuwenden, um diesen in einer veränderten Form dem Stream wieder zur Verfügung zu stellen. Konkret, mit dem Operator map wird der Boolean aus dem Stream in ein ValidationErrors-Objekt transformiert und an den Stream weiter geleitet.

Wann übrigens eine Validierung stattfinden soll, kann im Template mittels ngModelOptions im Property UpdateOn bestimmt werden. Folgende Möglichkeiten stehen zur Verfügung:

Property	Bedeutung
Blur	Validierung erfolgt, wenn der Benutzer das Eingabefeld verlässt.
update	Bei jeder Veränderung des Wertes im Eingabefeld, oder beim Eintippen eines Wertes nach jedem Buchstaben.
submit	Zum Zeitpunkt, wenn das Formular abgeschickt wird.

Übrigens lohnt es sich, den Decorator einer Directive genauer unter die Lupe zu nehmen. Hier bestehen Möglichkeiten, das Verhalten und weitere Eigenschaften zu definieren. Z.B. auf welche Formulare eine Directive angewendet werden soll etc.

 

Conclusion

Bei der Anwendung von Template-Driven entfällt viel Implementationsaufwand und oft ist diese Methode hinreichend, um übliche Anforderungen zu erfüllen. Wie auch im konkreten Fall, wo ein Http-Service verwendet wird. Ein durchaus grosser Vorteil dieser Methode ist, dass Validierungen angepasst werden können, ohne dabei eine Zeile Typescript hinzuzufügen. Dies kann unkompliziert in der Form erweitert werden. Jedoch übersteigt die Projektgrösse ein bestimmtes Mass, führt diese Methode zu einer schlechteren Übersicht. Zudem verkompliziert sich bei kombinierten Anwendungen die Integration von synchronen und asynchronen Anwendungsblöcken.

Reaktive-Driven

 Die Funtionsweise

Bei Reaktiven Template steht das Model im Vordergrund. Auch hier kann im Template eine lokale Variable verwendet werden, welche ihre Daten aus dem Model bezieht.  Dies geschieht nicht wie bei Template-Driven automatisch, sondern wird über den Konstruktor in das Model injected. Um diese Technologie anzuwenden, muss im Hauptmodule (app.module.ts) ReactiveFormsModule hinzugefügt werden.

Im Modell wird die FormGroup instanziert. Sie dient als Bindeglied zum Formular.

reaktiv-form.component.ts

 

Die durch NgForm instantierte  FormGroup der obersten Ebene verbindet das Formular, um den aggregierten Formularwert und den Überprüfungsstatus – wie zuvor beschrieben – zu verfolgen.
customerFormGroup stellt somit für jedes Feld ein FormControl mit den gewünschten Validierungs- und Statiprüfungen zur Verfügung. Somit aggregiert Formgroup den Zustand von allen FormControls. Ist ein FormControl nicht valide, ist auch FormGroup nicht valide. 

. Dabei sieht der Aufbau im Formular wie folgt aus:

Im Model muss nur noch ein Getter wie folgt zur Verfügung gestellt werden,

um auf das entsprechende Objekt im Form zuzugreifen.

Auf diesen  Getter kann verzichtet, jedoch müsste aber folgender Schreibweise angewendet werden.

Dadurch wird jedoch das Form eher unleserlich.

 

Die Klasse FormGroup

Zentral von Bedeutung bei der Validierung von Daten ist beim reaktiven Modell die Klasse Formgroup. Wie erwähnt, Formgroup ist das Bindeglied zu ngForm-Direktive und aggregiert sämtliche zugewiesenen Formcontrols. (siehe reaktiv-form.component.ts).
Im Überblick sind hier die wichtigsten Properties und Methoden aufgeführt.

Properties/Methode	Bedeutung
submitted	Gibt zurück, ob eine Form-Übermittlung ausgelöst wurde
errors	Gibt an, ob ein Form fehlerhaft ist. Tritt mindestens ein Fehler in einem Eingabefeld auf, hat die Variable den Wert «true»
touched	Gibt an, ob ein Eingabefeld den Fokus erhielt oder ein Mouse-Event ausgelöst wurde.
dirty	Wird ein Wert in einem Eingabefeld nach der Eingabe verändert, hat die Variable «dirty» den Wert true
resetForm()	Alle Eingabefelder werden zurückgesetzt.
controls	Gibt ein Instanz der FormControl aus der FormGroup zurück.

Weitere detaillierte Infos sind hier zu finden.

 

Conclusion

Die Technologie Reactive-Forms wirkt aus meiner Sicht übersichtlicher und stellt für aufwendigere Validierungen die bessere Lösung dar. Dieser Ansatz kommt vor allem dann zum Tragen, wenn Forms dynamisch geladen werden oder eine Applikation mehrsprachig funktionieren muss.

Das Akronym “SOLID” beschreibt Prinzipien, die beim Entwurf eines objektorientierten Designs zu berücksichtigen sind. Durch das Einhalten dieser Prinzipien werden entscheidend wichtige Qualitätsmerkmale in der Softwareentwicklung wie Stabilität, Wartbarkeit, Testbarkeit, Erweiterbarkeit etc. erreicht. Dieses Prinzipien kann sowohl auf Klassen wie auch auf Komponenten angewendet werden.

 

Wie definiert sich Solid?

Solid präsentiert sich mittels folgenden Prinzipien:

S	Single-Responsibility-Prinzip Das Single-Responsibility-Prinzip besagt, dass jede Klasse nur eine einzige Verantwortung haben soll. Sie sollen die Verantwortung über bestimmte abgegrenzte Aktivitäten beinhalten und nur eine bestimmte Menge an Informationen haben. Ein Beispiel liefert die Klasse Person, die nebst Angaben zu einer Person eine Funktion einer AHV-Nr.-Validierung beinhaltet. Hier treffen wir auf zwei unterschiedliche Verantwortlichkeiten Erstens: Alles was zu einer Person gehört Zweitens: Die AHV-Nr.-Validierung, welche nicht zum Aufgabenbereich dieser Klasse gehört, obwohl eine Person eine AHV-Nummer besitzt. Diese Verantwortlichkeiten müssen getrennt werden. Je besser sich eine Klasse auf eine Verantwortung oder Aufgabe konzentriert, je höher ist ihre Kohäsion* Bei diesem Prinzip ist auch dieser Grundsatz einzuhalten: “Es sollte nie mehr als einen Grund dafür geben, eine Klasse zu ändern.“ Wenn in einer Klasse nur Funktionen vorhanden sind, die zur Erfüllung einer Aufgabe beitragen, sollte es auch nicht mehr als einen Grund geben, sie zu ändern.
O	Open/closed Prinzip Komponenten sind so zu bauen, dass Erweiterungen ohne Änderungen des bestehenden Quellcodes möglich sind. Schnittstelle und Verhalten dürfen sich nicht ändern. Änderungen und Erweiterungen erfolgen in neuem Code. Hier ein Beispiel einer Log-Komponente, welches dieses Prinzip berücksichtigt: 1.) Definieren einer Schnittstelle interface ILogger { void Log(string message); } 1 2 3 4 interface ILogger {     void Log(string message); } 2.) Erstellen der Klasse ConsoleLogger, welche Logs auf dem Bildschirm aus gibt. Diese Klasse implementiert die Schnittstelle ILogger. class ConsoleLogger : ILogger { public void Log(string message) { Console.WriteLine(message); } } 1 2 3 4 5 6 7 class ConsoleLogger : ILogger {     public void Log(string message)     {         Console.WriteLine(message);     } } 3.) Erstellen der Klasse LogEngine, welche ebenfalls ILogger implementiert. Über den Konstruktor wird eine Instanz der Klasse ConsoleLogger zur Verfügung gestellt. class LogEngine : ILogger { private ILogger _logger = null; public LogEngine(ILogger logger) { this._logger = logger; } public void Log(string message) { _logger.Log(message); } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 class LogEngine : ILogger {     private ILogger _logger = null;       public LogEngine(ILogger logger)     {         this._logger = logger;     }         public void Log(string message)     {         _logger.Log(message);     } } Dieser Klasse LogEngine können beliebige Implementationen übergeben werden, indem diese Objekte im Konstruktor injiziert* werden. Kommt z.B. eine neue Anforderung hinzu, dass z.B. die Software Log-Informationen in die Datenbank schreiben soll, muss am bestehenden Code nichts geändert werden. Es benötigt nur eine neue Klasse, welche  die Schnittstelle ILogger implementiert und dafür sorgt, dass die Daten in die Datenbank geschrieben werden. Dies könnte dann wie folgt aussehen: class DbLogger : ILogger { public void Log(string message) { using (var context = new myModel()) { context.Log.Add(new Log() { Message = message }); context.SaveChanges(); } } } 1 2 3 4 5 6 7 8 9 10 11 class DbLogger : ILogger {     public void Log(string message)     {         using (var context = new myModel())         {             context.Log.Add(new Log() { Message = message });             context.SaveChanges();         }     } } Download executable In der Praxis treffen wir oft auf Beispiele wie Folgendes, welches gegen dieses Prinzip verstösst, weil der bestehende Code verändert wird. public void WriteLog(Log log) { if (log.Type = consoleLog) { WriteToConsole(log) } else if (logType.Type = fileLog) { WriteToFile(log) } //Um folgendes "else if" wird der Code erweitert. //Änderungen am bestehenden Code sind vermeiden! else if (logType.Type = fileDB) { WriteToDB(log) } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public void WriteLog(Log log) {     if (log.Type = consoleLog)     {         WriteToConsole(log)     }     else if (logType.Type = fileLog)     {         WriteToFile(log)     }     //Um folgendes "else if" wird der Code erweitert.     //Änderungen am bestehenden Code sind vermeiden!     else if (logType.Type = fileDB)     {         WriteToDB(log)     } }
L	Liskovsches Substitutionsprinzip Das Liskovsches Substitutionsprinzip (LSP) oder Ersetzbarkeitsprinzip fordert, dass eine Instanz einer abgeleiteten Klasse sich so verhalten muss, dass jemand, der meint, ein Objekt der Basisklasse vor sich zu haben, nicht durch unerwartetes Verhalten überrascht wird, wenn es sich dabei tatsächlich um ein Objekt eines Subtyps handelt. Hier ein Beispiel, welches gegen dieses Prinzip verstosst: Es beseht die Superklasse wie folgt: public class Rectangle { private int Height { get; set; } private int Width { get; set; } void ChangeHeight(int height) { Height = height; } void ChangeWidth(int width) { Width = width; } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 public class Rectangle {      private int Height { get; set; }        private int Width { get; set; }        void ChangeHeight(int height)      {          Height = height;      }        void ChangeWidth(int width)      {          Width = width;      } } Nun wird eine neue Klasse Square benötig. Diese wird von der Klasse Rectangle abgeleitet. public class Square : Rectangle { … 1 2 3 public class Square : Rectangle {    … Somit stellt die Klasse Square die Methoden ChangeHeight und ChangeWidth zur Verfügung. Aber was geschieht, wenn diese beiden Funktionen aufgerufen werden? Dann wird eine Seite es Quadrat verändert und folglich ist das Objekt dann kein Quadrat mehr, sondern ein Rechteck. Die Methode ChangeHeight  und ChangeWidth verhalten sich anders als erwartet.
I	Interface-Segregation-Prinzip Das Interface-Segregation-Prinzip oder Schnittstellenaufteilungsprinzip besagt, dass grosse Schnittstellen in mehrere kleinere aufzuteilen sind, damit die zu implementierenden Klassen nicht unnötige Methoden beinhalten. Betrachten wir dies am Beispiel der CRUD-Operationen. Je nach Rolle ist es nur erlaubt, nur Daten zu lesen. andere rollen dürfen nebst Lesen auch Daten ändern oder hinzufügen.  Damit gäbe es für unterschiedliche Rollen unterschiedliche Interfaces. So könnte es z.B. ein Interface geben, das nur das Lesen von Daten erlaubt und eines, das zusätzlich die Modifikation erlaubt. So kann beim Lesen von Daten auf IRead zugegriffen werden – mit einem weit schlankeren Interface. Hier ein Beispiel, was die Folgen davon sind, wenn Schnittstellen nicht optimal definiert sind: Da die Klasse Repository das Interface IDataOperation implementiert, jedoch nur lesender Datenzugriff erlaubt ist, muss demzufolge diese Klasse die Methode Add, Edit und Delete trotzdem beinhalten. Demzufolge werden diese Methoden wie im folgenden Beispiel zur Verfügung gestellt, jedoch nicht mit einer sinnvollen Implementierung bzw. so,  dass bei der Verwendung eine Exception geworfen wird. Im folgenden Beispiel wird die beschriebene Problematik verdeutlicht: class Repository : IDataOperation { public Person Read(int? id) { using (var db = new MyContextDB()) { return result = db.Person.SingleOrDefault(b => b.id == id); } } public void Add(Person person) { throw new NotSupportedException(); } public void Delete(int? id) { throw new NotSupportedException(); } public void Edit(int? id) { throw new NotSupportedException(); } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26     class Repository : IDataOperation     {         public Person Read(int? id)         {             using (var db = new MyContextDB())             {                 return result = db.Person.SingleOrDefault(b => b.id == id);             }         }           public void Add(Person person)         {             throw new NotSupportedException();         }           public void Delete(int? id)         {             throw new NotSupportedException();         }           public void Edit(int? id)         {             throw new NotSupportedException();         }       } Finden Sie also NotImplemtedException bzw. NotSupportedException im Code, könnte dies ein Indiz für die Verletzung des Interface-Segregation-Prinzip sein.     Besser zu lösen wäre die obige Aufgabe gemäss folgenden Beispiel, indem wir Schnittstellen verwenden, welche zu den erwartenden Aufgaben einer Klasse gehören. public class Repository : IRead, IModify { public void Modify(Person person) { using (var db = new MyContextDB()) { var result = db.Person.SingleOrDefault(b => b.id == id); if (result != null) { result.SomeValue = "Some other value"; db.SaveChanges(); } } } public Person Read(int? id) { using (var db = new MyContextDB()) { return result = db.Person.SingleOrDefault(b => b.id == id); } } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23     public class Repository : IRead, IModify     {         public void Modify(Person person)         {             using (var db = new MyContextDB())             {                 var result = db.Person.SingleOrDefault(b => b.id == id);                 if (result != null)                 {                     result.SomeValue = "Some other value";                     db.SaveChanges();                 }             }         }           public Person Read(int? id)         {             using (var db = new MyContextDB())             {                 return result = db.Person.SingleOrDefault(b => b.id == id);             }         }     }
D	Dependency-Inversion-Prinzip Das Dependency Inversion Principle (DIP) beschäftigt sich mit der Abhängigkeit von Modulen. Im Allgemeinen wird das DIP wie folgt beschrieben:Module höherer Ebenen sollten nicht von Modulen niedrigerer Ebenen abhängen. Beide sollten von Abstraktionen abhängen. Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen.Hier ein Beispiel, welches diesem Prinzip gerecht wird:1.) Definieren einer Schnittstelle public interface ILight{ void On(); void Off(); } 1 2 3 4 public interface ILight{     void On();     void Off(); } 2.) Implementieren ILight public class Light : ILight { private bool IsOn = false; public void Off() { IsOn = false; } public void On() { IsOn = true; } } 1 2 3 4 5 6 7 8 9 10 11 12 13 public class Light : ILight {     private bool IsOn = false;     public void Off()     {         IsOn = false;     }       public void On()     {         IsOn = true;     } } 3.) Implemetieren Switch public class Switch { private ILight switchClient; private Boolean switchClientPressed; public Switch(ILight switchClient) { this.switchClient = switchClient; } public void Press() { switchClientPressed = !switchClientPressed; if (switchClientPressed) { this.switchClient.Off(); } else { this.switchClient.On(); } } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 public class Switch {     private ILight switchClient;     private Boolean switchClientPressed;         public Switch(ILight switchClient)     {         this.switchClient = switchClient;     }         public void Press()     {         switchClientPressed = !switchClientPressed;         if (switchClientPressed)         {             this.switchClient.Off();         }         else         {             this.switchClient.On();         }     } } Download Executable In diesem Beispiel wird der Klasse Switch einfach eine Instanz der Klasse Light im Konstruktor mitgegeben. Switch stellt nur Methoden  wie z.B. Press zur Verfügung, welches mit der Methoden des übergebenen Objektes interagiert. Dadurch werden Abhängigkeiten verhindert. Hier ein Beispiel, welches gegen dieses Prinzip verstösst : public class Switch { Light light = new Light(); public void Press() { if (this.light.IsOn) { this.light.Off(); } else { this.light.On(); } } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 public class Switch {     Light light = new Light();       public void Press()     {                      if (this.light.IsOn)         {             this.light.Off();         }         else         {             this.light.On();         }     }   } In der Klasse Switch wird die Klasse Light instanziert. Dadurch erzeugen wir eine Abhängigkeit zwischen diesen beiden Klassen. Grundsätzlich kann gesagt werden, “wenn in einer Klasse eine andere Klasse instanziert wird, entsteht eine Abhängigkeit”.

 

Kohäsion*

Kohäsion ist ein Mass , wie gut eine Aufgabe bzw. eine Verantwortung mittels Software abgebildet wird. Kümmert sich eine Klasse nur um eine Aufgabe (Single-Responsibility-Prinzip ist erfüllt), so hat sie eine sehr hohe Kohäsion. Kümmert sie sich um viele verschiedene, nicht zusammengehörige Aufgaben, so hat sie eine geringe Kohäsion. Manager-Klassen haben typsicherweise eine sehr geringe Kohäsion.

 

Injiziert*

Eine Technik, wo ein Objekt über den Konstruktor eines anderen Objektes übergeben bzw. injiziert wird. Diese Technik wird bei Dependency Injection angewendet.