Strict Standards: Declaration of Walker_Page::start_lvl() should be compatible with Walker::start_lvl(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::end_lvl() should be compatible with Walker::end_lvl(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::start_el() should be compatible with Walker::start_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::end_el() should be compatible with Walker::end_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_PageDropdown::start_el() should be compatible with Walker::start_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1244

Strict Standards: Declaration of Walker_Category::start_lvl() should be compatible with Walker::start_lvl(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::end_lvl() should be compatible with Walker::end_lvl(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::start_el() should be compatible with Walker::start_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::end_el() should be compatible with Walker::end_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_CategoryDropdown::start_el() should be compatible with Walker::start_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1442

Strict Standards: Redefining already defined constructor for class wpdb in /www/htdocs/v167612/wplog/wp-includes/wp-db.php on line 306

Strict Standards: Redefining already defined constructor for class WP_Object_Cache in /www/htdocs/v167612/wplog/wp-includes/cache.php on line 433
iFool » Validierung der Benutzereingaben innerhalb der Domainklasse
Home > Allgemein, Groovy & Grails > Validierung der Benutzereingaben innerhalb der Domainklasse

Validierung der Benutzereingaben innerhalb der Domainklasse

validierung_messagesDomainklassen bestimmen hauptsächlich die Eigenschaften der Businessobjekte und die Beziehungen dieser Objekte untereinander. Zu den Eigenschaften gehört die Anzahl, Art und Ausprägung der einzelnen Attribute.

Die Art und Anzahl der Attribute wird durch Deklaration einzelner Objekte und einfacher Datentypen im Kopf der Klasse vorgenommen. Wie kann der Entwickler dann Einfluss auf die gültigkeit der Benutzereingaben nehmen? Hier geht es um Validierung…

In der Abbildung wird ein “Create-Dialog” für eine Domainklasse “Archiv” gezeigt, die 2 Attribute enthält: Name des Archivs und Beschreibung.  Der Benutzer hat mit seinen Eingaben gegen 2 Validierungsregeln verstoßen und ich möchte kurz einmal zeigen, wie soetwas funktioniert.

Schauen wir uns zunächst einmal die relevanten Teile der Implementierung der “Domainklasse Archive” an:

 class Archive {

    String archive
    String archiveDescription

    static constraints = {
        archive(blank:false, maxSize:3, unique:true, validator: {
                String itString = (String) it
                if (itString.toUpperCase().equals(itString)){
                    return true
                } else {
                    return ['archive.archive.notuppercase', itString]
                }
        })
        archiveDescription(blank:false, maxSize:256)
     }
}

Die Validierungsregeln werden in der static constraints-Closure hinterlegt. In diesem Bereich wird durch die Reihenfolge der Nennung der Attribute [1. archive() und 2. archiveDescription()] vorgegeben, welche Reihenfolge für die Attribute später bei der Generierung der Views (=Positionierung der Felder in der Maske) von GRAILS gewählt werden soll.
Innerhalb der Klammern [von z.B. archive(...)] stehen dann die eigentlichen Validierungsregeln. Hier kann man zwischen Standardregeln und individuell formulierten Regeln unterscheiden.

Die hier verwendeten Standardregeln bedeuten folgendes:

blanks:false Hier muss ein Feldwert eingegeben werden. Keine Eingabe oder nur Leerzeichen sind nicht erlaubt.
maxsize:3 Es dürfen höchstens 3 Zeichen eingegeben werden
unique:true Dieses Attribut muss unter allen Objekten dieser Klasse einzigartig sein. Im Beispiel heisst das: Der Archivname darf in der Datenbank nur einmal vorkommen!

Das sind nur 3 Beispiele für viele Standard-Validierungen, die bereits jetzt verfügbar sind. Eine Ãœbersicht findet man auch hier. Sehr interessant ist zum Beispiel auch “inList”, bei der man eine Liste der möglichen Ausprägungen gleich angeben kann. Die werden dann dem Benutzer als Drop-Down-Liste präsentiert und eine freie Eingabe und die damit verbundenen Eingabefehler sind überhaupt nicht mehr möglich.

Das bedeutet, innerhalb der Validierungsregeln werden neben der Validierung der Eingaben und der Reihenfolge der Steuerelemente auch die Typen der Steuerelemente (Textfeld, Textarea, Selection etc.) vorbestimmt.

Jetzt komme ich zu der Bedingung, die oben im Sourcecode hinter validator: formuliert wurde:
it ist hier immer verfügbar und repräsentiert die aktuell zu prüfende Ausprägung des Attributs. Hier also das, was der Benutzer als den Archivnamen eingegeben hat. Sollte er nur Ziffern und große Buchstaben verwenden ist die Validierung okay,- es wird true zurückgegeben. Andernfalls ist der Rückgabewert eben nicht true und das löst immer eine GRAILS-Fehlerreaktion aus.

messagefilesBei Verwendung von false als Rückgabewert innerhalb von validator: “zieht” GRAILS eine Standard-Fehlermeldung. Im vorliegenden Beispiel wird aber eine individuell formulierte Nachricht sprachabhängig zurückgegeben.

Die Fehlermeldungen (”flash-messages”), die GRAILS bei Verstößen sendet entstammen den messages.properties-Files. Diese Nachrichtendateien können um eigene Nachrichten erweitert werden. Im obigen Beispiel wird die Nachricht mit der id “archive.archive.notuppercase” zusammen mit der falschen Benutzereingabe “itString” als Parameter zurückgegeben.

Da hier die Nachricht “archive.archive.notuppercase” im deutschen Nachrichtenfile “messages_de.properties” hinterlegt wurde wird Sie von GRAILS als Fehlermeldung angezogen (vgl. Screenshot am Beginn des Artikels).

So sieht die verwendete Nachrichtendefinition aus:

 archive.archive.notuppercase = "{3}" ist kein erlaubter Archivname. Bitte nur GROßBUCHSTABEN benutzen!

Und so wird sie zur Laufzeit (bei der Falscheingabe “s”) Umgesetzt:

archivearchivenotuppercase

Was noch abschließend zu sagen wäre: Die Parameter, auf die sich die Nachrichten beziehen können haben eine festgelegte Reihenfolge:

{0}: Name der Eigenschaft/des Attributs
{1}: Domainklasse
{2}: Eingegebener Wert
{3}: Vom Entwickler mitgelieferter Parameter
 

Allgemein, Groovy & Grails

  1. Bisher keine Kommentare
  1. Bisher keine Trackbacks