Roberto's Blog : Validation

ASP.NET Mvc 3 unobtrusive validation - erweitern mit eigenen jQuery Adaptern und Validatoren

Roberto — Thu, 13 Jan 2011 07:30:00 GMT

Grundsätzlich gibt es serverseitig zwei Möglichkeiten die eigenen Attribute für die Validierung zu Gestalten:

Implementierung einer Basisklasse wie RegularExpressionAttribute sowie des Interfaces IClientValidatable
Implementierung einer Basisklasse wie RegularExpressionAttribute und den Einbau eines DataAnnotationsModelValidator

Im Prinzip hat der letzte Post gezeigt, dass ein jQuery Adapter die Konvertierung von HTML5 Attributen in die für jQuery kompatiblen Metadaten vornimmt.

Diese HTML5 Attribute haben alle die selbe Form: data-val-<xxx>

Als Beispiel gibt es bereits vordefinierte Konstellationen wie data-val-regex und data-val-regex-pattern.

Somit würde der im Hintergrund stehende Adapter nichts anderes machen, als zu überprüfen, ob ein Feld mit dem Attribut data-val-regex gesetzt ist und wenn ja, das dazugehörige pattern auslesen und validieren.

Im nachstehenden Beispiel wird ein eigenes, triviales Email Attribut erstellt, um die Umsetzung etwas deutlicher zu erklären.

Möglichkeit 1) IClientValidatable

Das Attribut

public class EmailWithoutValidatorAttribute : RegularExpressionAttribute, IClientValidatable 
{ 
    public EmailWithoutValidatorAttribute() : base(@"<emailregex>")
    {

    }
 
    public IEnumerable<ModelClientValidationRule> GetClientValidationRules(ModelMetadata metadata, 
                                                                             ControllerContext context)
    {
        var rule = new ModelClientValidationRule(...);
        return new[] { rule };
    }
}

Eigentlich nur ein RegularExpressionAttrubite wie von früheren Zeiten gewohnt, sowie eine zusätzliche Methode GetClientValidationRules, die die Rückgabe einer Liste von Regeln erwartet. Ob eine oder mehrere Regeln zurückgegeben werden, ist irrelevant.

Nun reicht eine normale ModelClientValidationRule für das Vorhaben nicht aus, somit wird eine eigene erstellt. Diese hat den Vorteil, dass ein eigener validationType (Der eigentliche Name des Adapters, der später benötigt wird) angegeben werden kann.

public class NamedRegexValidationRule : ModelClientValidationRule
{
    public NamedRegexValidationRule(string errorMessage,
                               string pattern, string validationType)
    {
        this.ErrorMessage = errorMessage;
        this.ValidationType = validationType;
        this.ValidationParameters.Add("pattern", pattern);
    }
}

Die im Code gezeigten ValidationParemeters können beliebig gefüllt werden, benötigt wird hier ausschließlich das Pattern.

Hinweis: Die <string, object> collection kann beliebig gefüllt werden. Letztendlich wird jedes Element als ein html Attribut data-val-<string>="<value>" gerendert. Es ist somit egal, ob "pattern" oder "blubr" vorkommt.

Die angepasste Methode im Attribut würde somit wie folgt aussehen (Wichtig ist der Name „customemail“, dieser wird als Adaptername verwendet und kann ausschließlich mit Kleinbuchstaben angegeben werden)

public IEnumerable<ModelClientValidationRule> GetClientValidationRules(ModelMetadata metadata, 
                                                                         ControllerContext context)
{
    var rule = new NamedRegexValidationRule(this.ErrorMessage, this.Pattern, "customemail");
    return new[] { rule };
}

Angenommen es ist ein Model "Person" mit einer Eigenschaft "Email" vorhanden, die mit dem eben erstellen Attribut versehen ist:

public class Person
{
    [EmailWithoutValidator(ErrorMessage = "Not a valid email.")]
    public string Email { get; set; }
}

Das dazugehörige Feld als gerenderter Version @Html.TextBoxFor(p => p.Email)

<input type="text" value="" name="Email" id="Email" class="input-validation-error"
    data-val-customemail-pattern="<EmailPattern>" 
    data-val-customemail="Not a valid email." 
    data-val="true">

Zwei Sachen wurden damit erreicht:

data-val-customemail steht für die angegebene Fehlermeldung.
data-val-customemail-pattern steht für das angegebene Email Pattern.

Möglichkeit 2) DataAnnotationsModelValidator

public class EmailWithValidatorAttribute : RegularExpressionAttribute
{
    public EmailWithValidatorAttribute() : base(@"<EmailRegex>")
    {
    }
}

Nichts anderes als bei Möglichkeit 1, ohne der Implementierung des IClientValidatable Interfaces und somit der Erstellung der Regeln.

Diese werden bei dieser Variante in den Validator ausgelagert:

public class EmailValidator : DataAnnotationsModelValidator<EmailWithValidatorAttribute>
{
    private readonly string _errorMessage;
    private readonly string _pattern;

    public EmailValidator(ModelMetadata metadata, ControllerContext context, EmailWithValidatorAttribute attribute) 
                       : base(metadata, context, attribute)
    {
        this._errorMessage = attribute.ErrorMessage;
        this._pattern = attribute.Pattern;
    }

    public override IEnumerable<ModelClientValidationRule> GetClientValidationRules()
    {
        var rule = new NamedRegexValidationRule(this._errorMessage, this._pattern, "customemail");
        return new[] { rule };
    }
}

Auch hier gibt es eine Methode GetClientValidationRules(), die eigentlich die selbe Logik beinhaltet, wie in Möglichkeit 1.

Zusätzlich muss der Validator nun in der Global.asax (In der application start Methode) noch mit Angabe des Attributes registriert werden:

DataAnnotationsModelValidatorProvider.RegisterAdapter(
                            typeof(EmailWithValidatorAttribute), 
                            typeof(EmailValidator));

Im Prinzip bringen beide Möglichkeiten das selbe Ergebnis, Möglichkeit 1 hat den Nachteil (zumindest für den ein oder anderen), dass die Logik direkt im Attribut steht und Möglichkeit 2 lagert dies in einen externen Validator aus. Somit ist das Attribut nicht MVC abhängig und könnte auch für andere Zwecke verwendet werden, bzw. bereits vorhandene Attribute könnten problemlos wiederverwendet werden.

Last but not least, der clientseitige Aufbau des Adapters.

Die jQuery unobtrusive validation Bibliothek stellt eine Methode Add() zur Verfügung, über welche neue, eigene Adapter registiert werden können. Diese nimmt als Parameter einmal den Adapternamen, den/die Attributnamen die benötig werden, sowie eine Funktion, über die die eigene Logik implementiert werden kann.

jQuery.validator.unobtrusive.adapters.add("customemail", ["pattern"], function (options) {

    if (options.element.tagName.toUpperCase() == "INPUT") {

        // Set the regex rule with the given pattern.
        options.rules["regex"] = options.params.pattern;

        if (options.message) {
            options.messages["regex"] = options.message;
        }
    }
});

Wie im letzten Post gezeigt, beinhaltet das options Objekt Regeln, Parameter und Mitteilungen, über die die Validierung gesteuert wird.

In Falle einer Email Validierung reicht eine regex Regel aus, es können aber beliebig viele hinzugefügt werden. Wichtig ist hierbei nur, dass diese als Paremter angegeben werden ["pattern", "<anderes Attribut">, ...]

Natürlich macht es nicht wirklich viel Sinn, ein Email Attribut so kompliziert zu gestalten, viel mehr geht es darum zu zeigen, wie es im Verhältnis doch einfach ist, eigene Adapter zu erstellen. Im Web 2.0 Zeitalter ist eine kombination aus client und server Validierung eher Standard als eine Ausnahme. Mit ein bisschen Mühe können tolle Sachen, wie bspw. eine Überprüfung, ob ein Username einzigartig ist entwickelt werden. Der Große Vorteil liegt auch hier in der Entkoppelung der Validierungslogik vom restlichen Teil der Anwendung.

Anbei gibt’s wie immer das Beispiel zum Post.

ASP.NET MVC 3 unobstrusive custom validation sample.

ASP.NET unobtrusive validation - Clientseitige Adapter

Roberto — Mon, 27 Dec 2010 13:15:00 GMT

Wie bereits im letzten Post beschrieben, gibt es seit der dritten Version des MVC Frameworks die Möglichkeit, Formular Validierungen über HTML 5 kompatible Attribute zu machen.

Diese werden clientseitig über Adapter umgesetzt, die die entsprechenden Parameterwerte aus den HTML 5 Attributen in die für jQuery Validate vorgesehenen Metadaten konvertieren.

In diesem Post wird nicht genauer auf das jQuery Validate Plugin eingegangen, sondern mehr über die Logik und Konvertierungsmechanismen der Adapter.

Mehr Informationen zu jQuery Validate finden sich hier.

Als weiteres, für den Post relevanteres Plugin findet sich das jQuery.validator.unobtrusive.adapters.js im Ordner Scripts eines jeden MVC3 Projekttemplates.

Im Script gibt es eine Registrierungsmethode "add", sowie einige allgemeine Methoden "addBool", "addSingleVal" und "addMinMax".

Im Grunde sind die meisten Fälle damit abgedeckt, als Beispiel ein Auszug aus der eben genannten Datei:

adapters.addBool("creditcard").addBool("date").addBool("digits").addBool("email").addBool("number").addBool("url");
adapters.addSingleVal("accept", "exts").addSingleVal("regex", "pattern");
adapters.addMinMax("length", "minlength", "maxlength", "rangelength").addMinMax("range", "min", "max", "range");

Bevor genauer auf die einzelnen Methoden eingegangen wird, eine kurze Erklärung zur Methode "add", die intern von jeder aufgerufen wird:

adapters.add = function (adapterName, params, fn)
{
....
}

adapterName: Ist der Name des zu hinzuzufügenden Adapters. Im Prinzip nichts anderes, als der im Attribut data-val-<Name> vorkommenden Platzhalter.

params: Ist ein optionales Array aus Parametern, die aus den Attributen data-val-<Name>-<Paremter> extrahiert werden.

fn: Ist die Funktion, welche die Werte der Html Attribute in die für "jQuery Validate" benötigten Regeln und/oder Mitteilungen konvertiert.

Die Methode addBool macht somit einen in etwa ähnlichen Aufruf:

add("email", function(options) {
    ...
    options.rules["required"] = true;
    ...
});

Hinweis: Das option Element beinhaltet folgende Werte:

element: Das HTML Element dem der Validator zugeordnet ist.

form: Das HTML Form Element.

message: Die Ausgabe, die ebenfalls aus den HTML Attributen extrahiert wird.

params: Ein Array Element mit Werten, die aus den HTML Attributen extrahiert werden. (Bspw. var min = options.params.min)

rules: Das Array Element, das die Namen und Werte beinhaltet, die wiederum für die jQuery Validate Regel benötigt werden. (Bspw. ["required"] = true)

messages: Ein Array Element, das die Namen und Werte beinhaltet, wobei der Name für die verletze Regel und der Wert für die dazugehörige Ausgabe stehen. (Bspw. ["required"] = "Das Feld darf nicht leer sein.")

Nun sollte auch die addSingleValue anhand eines Beispiels verständlich werden:

adapters.addSingleVal("regex", "pattern");

Gegeben ist ein HTML Element, wobei die Eingabe nicht leer sein kann und es nur Großbuchstaben beinhalten darf. (= dem Regex [A-Z] enstprechen).

<input ... 
data-val="true"
data-val-required="Das Feld darf nicht leer sein."
data-val-regex="Das Feld darf nur Großbuchstaben beinhalten."
data-val-regex-pattern="[A-Z]" />

Folgende Werte würden daraus entstehen:

-> options.rules["required"] = true
-> options.rules["regex"] = "[A-Z]"
-> options.messages["required"] = "Das Feld darf nicht leer sein."
-> options.messages["regex"] = "Das Feld darf nur Großbuchstaben beinhalten."

Und natürlich würde auch addMinMax nichts anderes machen, als ein paar "rules" wie bspw. "min", "max" zu setzen.

Am Besten einfach ein paar Testelemente machen und mit der Firefox Extension Firebug ansehen.

Im nächsten Teil wird dann genauer auf die Erstellung eigener Adapters eingegangen!

ASP.NET Mvc 3 unobtrusive validation

Roberto — Sun, 26 Dec 2010 10:55:00 GMT

In dieser dreiteiligen Postreihe wird gezeigt, wie sich ab ASP.NET Mvc 3 die Validierung von Formularen geändert hat, welche Vorteile sie mit sich bringt und wie die Validierung mit eigenen Regeln erweitert wird.

Bereits in MVC2 gab es eine client und serverseitige Validierung für Models.
Standartmäßig für den Client mit ASP.NET Ajax, aber auch mit einer kleinen jQuery Erweiterung machbar.

Bereits durch dieses Verfahren wurde der serverseitige Teil (Durch den Einsatz von DataAnnotations) vom Clientseitigen entkoppelt.

public class Mandant
{
    [Required(ErrorMessage = "Name is required.")]
    [StringLength(50, ErrorMessage = "Must be under 50 characters.")]
    [DisplayName("Mandant Name")]
    public string Name { get; set; }
}

Was im Html Code dabei gerendert wird, sieht in etwa so aus:

//<![CDATA[
if (!window.mvcClientValidationMetadata) { window.mvcClientValidationMetadata = []; }
window.mvcClientValidationMetadata.push({"Fields":[{"FieldName":"Mandant.Name","ReplaceValidationMessageContents":true,"ValidationMessageId":"Mandant_Name_validationMessage","ValidationRules":[{"ErrorMessage":"Name is required.","ValidationParameters":{},"ValidationType":"required"},{"ErrorMessage":"Must be under 50 characters.","ValidationParameters":{"minimumLength":0,"maximumLength":50},"ValidationType":"stringLength"}]}, ...
//]]>

Ab der dritten Version des MVC Frameworks wird die Validierung hingegen etwas schicker gelöst.

Im Prinzip bringt die Neuerung den Vorteil mit sich, dass auf einen langen JSON String im Html code verzichtet wird und dafür auf HTML5 kompatible Attribute gesetzt wird, die die Validierung der Input Felder beschreiben.

<input type="text" value="" name="Name" id="Name" data-val-required="The Name field is required." data-val="true" class="input-validation-error">
<input type="text" value="" name="Age" id="Age" data-val-required="The Age field is required." data-val-number="The field Age must be a number." data-val="true" class="input-validation-error">

Ein weiterer Vorteil ist der Verzicht auf automatisch generierte IDs, da die Informationen nun direkt am Input Feld angefügt werden.

Um diese "unobtrusive" (Übersetzt: unauffällig, bescheiden) Validierung nutzen zu können, sind zwei einfache Schritte notwendig.

Folgende Script Bilbiotheken einbinden:

(Beim erstellen eines neuen MVC3 Projekts werden diese standartmäßig eingebunden)

<script src="@Url.Content("~/Scripts/jquery-1.4.1.min.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/jquery.unobtrusive-ajax.min.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/jquery.validate.min.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/jquery.validate.unobtrusive.min.js")" type="text/javascript"></script>

Dazu noch sicherstellen, dass in der Web.Config folgende Einstellungen gesetzt sind:

<appSettings>
    <add key="ClientValidationEnabled" value="true"/> 
    <add key="UnobtrusiveJavaScriptEnabled" value="true"/>
</appSettings>

Diese sind ebenfalls ab einem MVC3 Projekt-Template standartmäßig dabei, bei einem Upgrade von einer älteren Version müssen sie manuell hinzugefügt werden.

Die eben genannten Einstellungen sind Global für das ganze Projekt, natürlich gibts diese auch Kontext spezifisch:

HtmlHelper.ClientValidationEnabled = true;
HtmlHelper.UnobtrusiveJavaScriptEnabled = true;

Dazu wie gewohnt das Model mit den DataAnnotations versehen (siehe weiter oben) und das Ganze sollte funktionieren.

Und wie das Ganze im Hintergrund funktioniert?

Grundsätzlich hängt alles davon ab, ob das data-val="true" Attribut gesetzt ist.
Dieses wird dem Feld hinzugefügt, wenn mindestens eine Regel aktiv ist.
Die wohl am meisten verwendete Regel ist jene, die besagt, ob ein Feld ein Pflichtfeld ist. (Html Attribut dazu: data-val-required="true")
Natürlich gibt es zusätzlich verschiedene optionale Attribute wie data-val-length, data-val-length-min (max), data-val-range-min (max), data-val-regex, data-val-regex-pattern, usw.

Fazit:

Ich habe bereits ein Projekt umgestellt, es geht relativ fix und ist doch um einiges schöner - somit: man sollte sich die Arbeit antun.

Im nächsten Post wird genauer auf eigene jQuery Validators eingegangen, schaut also vorbei :-)

Anbei wie immer das Beispiel:

ASP.NET MVC 3 unobstrusive validation sample.