BigBasti's Blog About Me & my Digital Lifestyle

25Jan/124

ASP.NET MVC: HTML5 Elemente mit jQuery Fallback nutzen

Soo, nachdem ich die Überschrift mit all den hippen Begriffen vollgepackt habe die es in Sachen Web momentan so gibt möchte ich euch kurz erklären worum es in diesem Artikel gehen soll.

Ihr werdet sicher mitbekommen haben, dass HTML5 auf dem Vormarsch ist und auch wenn es immer noch nicht offiziell fertig ist findet man immer häufiger den HTML5-Header <!DOCTYPE html> auf diversen Seiten.

Eins der meiner Meinung nach nützlichsten Features die wir mit HTML5 erhalten sind die neuen Input-Typen. Denn bisher hatten wir keine Wahl und mussten type="text" benutzen!

Die Eingabefelder vom Typ Text konnten natürlich alles enthalten, sind aber nicht gerade Benutzerfreundlich wenn man etwas komplexere Daten eingeben soll wie zum Beispiel ein Datum.

In HTML5 wurden deswegen spezifische Typen für solche immer wieder einkehrende Eingaben eingeführt. Eine von ihnen ist &quot;Date&quot;:


Birthday: <input type="date" name="bday" />

Der große Vorteil hier ist, dass die Browser nun eine eigene Implementierung für diesen Typ von Eingabefeldern machen können. Falls der Browser nun also diesen neuen Eingabe Typ unterstützt blendet er automatisch einem (mehr oder weniger) schönen Date-Picker ein in dem man bequem das Datum wählen kann:

Ansicht des neuen Typen in verschiedenen Browsern

Ein weiterer großer Vorteil ist, dass auch die mobilen Browser wie z.B. auf dem iPhone diese neuen Elemente ebenfalls unterstützen und einen passenden Picker einblenden:

Date-Picker auf dem iPhone

Wie ihr in dem ersten Screenshot sehen könnt unterstützt der FireFox (zumindest zum Zeitpunkt des Screenshots) den neuen Typ nicht. In diesem Fall blendet er ein gewöhnliches Textfeld ein wo wir nun gezwungen sind das Datum auf die gewohnte (unbequeme) Weise einzutragen.

Übrigens, ich glaube ich muss euch nicht sagen warum der Internet Explorer hier nicht mit aufgeführt ist oder? ;-)

Und genau das ist das Problem um das es in diesem Blogpost geht. Wenn wir die tollen neuen Elemente nutzen gehen wir das Risiko ein, dass Nutzer die einen älteren Browser nutzen nicht in den Genuss einer bequemen Eingabe kommen.

jQuery Date-Picker

Wir könnten auch komplett auf das HTML5 Element verzichten und direkt alles mit jQuery machen, welches auch einen Date-Picker bietet, aber das ist auch nicht das gelbe vom Ei, denn dann wären die Mobilen Nutzer in Nachteil, da dort die Browser diese Elemente für gewöhnlich unterstützen und eine gewohnte Oberfläche für die Eingabe bieten.

Die Optimale Lösung ist offensichtlich eine Mischung beider Welten. Wenn der Benutzer die Seite mit einem kompatiblen Browser aufruft soll der Date-Picker des Browsers genutzt werden, wenn der Browser aber veraltet ist soll stattdessen der jQuery Fallback greifen und der JavaScript Date-Picker (siehe links) genutzt werden.

Zu unserem Glück macht uns ASP.NET MVC die Umsetzung dieses Plans sehr leicht, da es an den nötigen Stellen sehr einfach erweitert werden kann.

Schauen wir uns mal ein kleines Beispiel an. Wir haben eine Klasse Person, und wollen auch dessen Geburtstag speichern, hier wollen wir die tolle neue Funktionalität nutzen. Implementieren wir das Ganze jedoch erstmal wie gewohnt:


    public class Person
    {
        public int ID { get; set; }
        public String Name { get; set; }
        public DateTime Geburtstag { get; set; }
    }

Wenn wir die Model-Klasse haben können wir das MVC Scaffolding nutzen um für uns eine View zum Erstellen neuer Personen anzulegen:

MVC Scaffolding kommt uns zu Hilfe

Schauen wir uns nun doch mal an was da für uns tolles generiert wurde:


    <div class="editor-field">
        @Html.EditorFor(model => model.Geburtstag)
        @Html.ValidationMessageFor(model => model.Geburtstag)
    </div>

Auffällig hierbei ist, dass hier @Html.EditorFor genutzt wird und nicht etwa @Html.TextBoxFor! Der Hintergrund ist der, dass MVC bei der Generierung versuchen wird ein passendes Element für den angegebenen Datentyp (DateTime) zu bestimmen, aber da MVC standardmäßig nur den Typ Text kennt wird hier eigentlich immer ein Input-Element vom Typ text generiert.

Hier kommt uns die Erweiterbarkeit von MVC zu gute, denn wir können ganz einfach NuGet nutzen um uns die nötige Funktionalität zu verschaffen. Wir installieren das Packet MvcHtml5Templates.

Installation über NuGet

Neue Templates

Nachdem NuGet alles erledigt hat werdet ihr feststellen, dass ihr ein paar neue Dateien in eurem Views/Shared Verzeichnis habt (siehe Bild links). Und wie ihr schon an dem Namen erkennen könnt sind das die neuen Input-Typen aus HTML5.

Diese Templates machen im Grunde nichts anderes als die MVC-Eigenen zu überschreiben und versehen die mit dem passendem Type-Attribut.

Hier sind euch keine Grenzen gesetzt ihr könnt natürlich auch eire eigenen Templates definieren mit euren eigenen Typen. (Auch wenn man das eher selten benötigt)

Das Tolle: mehr müssen wir nicht machen. MVC wird nun zur Laufzeit statt einem Text ein Date Input-Element für uns anlegen. Beachtet, dass das nur geht wenn wir in der View die allgemeine Funktion @Html.EditorFor nutzen und keinen Spezifischen Typ angeben.

Schauen wir mal in den Sourcecode der zur Laufzeit für das Geburtstagsfeld generiert wird:


<input class="text-box single-line"
data-val="true"
data-val-required="Das Feld 'Geburtstag' ist erforderlich"
id="Geburtstag"
name="Geburtstag"
type="datetime"
value=""; />

Wie ihr seht wird nun der Korrekte Typ, nämlich datetime verwendet. Wenn wir die Seite nun also mit einem kompatiblen Browser aufrufen können wir ganz bequem das Datum wählen.

Leider ist der Opera Browser momentan wohl der einzige Desktop Browser der uns hier einen Benutzerfreundlichen Dialog einblendet (siehe erstes Bild oben), somit müssen wir dafür sorgen, dass die Benutzer mit anderen oder alten Browsern nicht benachteiligt werden.

JavaScript Magie

Auch für diese Problematik bringt MVC bereits alles mit was nötig ist sie zu lösen. Werfen wir doch mal einen Blick in unseren Scripts Ordner finden wir alle nötigen jQuery und jQuery UI Skripte, dazu kommt noch die modernizr Bibliothek die uns auch zu Gute kommen wird.

Die jQuery Bibliotheken liefern und die nötige Funktionalität die wir benötigen um diesen hübschen Date-Picker einzublenden.

Die modernizr Bibliothek dagegen hilft uns herauszufinden ob der Browser, den der Benutzer momentan verwendet die gewünschten HTML5 Features unterstützt.

Nun müssen wir also bei unseren Formularen prüfen, ob der Browser die nötigen Funktionen kennt und bei Bedarf die jQuery Klassen einbinden. Das Ganze ist dank der Einfachheit von Modernizr und jQuery ziemlich simpel.

Wechseln wir zu unserer View und fügen die Referenzen auf die nötigen Skripte und CSS Dateien ein:


<script src="@Url.Content("~/Scripts/jquery-1.5.1.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/jquery-ui-1.8.11.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/modernizr-1.7.js")" type="text/javascript"></script>
<link href="@Url.Content("~/Content/themes/base/jquery.ui.all.css")" rel="stylesheet" type="text/css" />

Unten in der View fügen wir nun eine Modernizr Abfrage ein und prüfen, ob der Browser das DateTime-Feld unterstützt, und wenn nicht lassen wir jQuery das Ganze für uns regeln:


<script type="text/javascript">
    $(function () {
        if (!Modernizr.inputtypes.date) {
            $("input[type='datetime']").datepicker();
        }
    });
</script>

Mit dem Befehl $("input[type='datetime']").datepicker(); werden alle Input-Felder vom Typ DateTime durch den jQuery Picker ersetzt. Coole Sache!

Unser Browser kennt den Typ nicht :(

Unser Browser kennt den Typ nicht :(

Kleiner Hinweis am Rande: Das ist nicht wirklich best practice da die Skripte auch geladen werden wenn sie gar nicht benötigt werden (der Browser kennt das HTML5 Feld) ich habe das hier der Einfachheit geopfert.

Und das wars auch schon! Alle Browser die das Feld unterstützen blenden nun ihren Picker ein, ansonsten wird der jQuery Fallback genutzt.

Wir müssen uns auch nicht mit irgendwelchen UserAgent-Prüfungen herumschlagen und lassen das alles Modernizr erledigen, der das intern über JavaScript prüft und somit immer aktuell ist. Das heißt dass wenn irgendwann der IE plötzlich die neuen Typen kennt werden diese auch funktionieren!

Genauso könnt ihr auch bei all den anderen neuen HTML5 Typen vorgehen und euren Usern ein bestmögliches Bedienerlebnis bereiten ;-)

kick it on dotnet-kicks.de

5Jan/120

ASP.NET MVC: Zugriff auf Dateien einschraenken

Oft kommt es vor dass man bestimmte Inhalte nicht der breiten Öffentlichkeit präsentieren möchte. So will man beispielsweise bestimmte Inhalte nur autorisierten Benutzern oder nur Admins zur Verfügung stellen, andere User die nicht eingeloggt sind sollen diese Inhalte nicht abrufen können. Ein weiterer Anwendungsfall wäre auch hotlinking zu verhindern.

Dieses Verhalten kann man in ASP.NET MVC über verschiedene Wege erreichen. Eine beliebte Möglichkeit ist es

die Dateien über einen Controller zu verteilen.

Hierbei erstellt man einen Controller der eine Action hat in der die gewünschte Datei geladen und an den Browser zurückgegeben wird. Hier hat man dann die Bequemlichkeit, dass man problemlos prüfen kann ob der User eingeloggt ist und über die nötigen Rechte für das Bild verfügt. Das geht zum Beispiel mit dem Authorized-Attribut für die Actions.

Implementiert würde so eine Action dann wohl ca so aussehen:


public ActionResult Image(string id)
{
    var dir = Server.MapPath("/Private/Images");
    var path = Path.Combine(dir, id + ".jpg");
    return base.File(path, "image/jpeg");
}

Das Bild kann man dann so abrufen:


<img src="@Html.Content("~/Content/Image/" + model.pictureID)" />

Dieser Ansatz funktioniert problemlos hat aber den kleinen Nachteil, dass er nicht so performant ist wie der direkte Zugriff auf die Ressource.

Eine weitere (und auch meine bevorzugte) Möglichkeit eine solche Zugriffskontrolle zu implementieren ist es durch

einen eigenen RouteHandler.

Eine Beispielimplementierung wie man auf diese Weise Hotlinking verhindern kann habe ich in Mike Brinds Blog gefunden.

Hier sind im Grunde drei kleine Schritte nötig um einen eigenen RouteHandler zum Laufen zu bekommen. (Code von Mikes Blog)

Zunächst müssen wir die RouteHandler Klasse anlegen, die das IRouteHandler Interface und dessen einzige Methode GetHttpHandler implementiert:


public class ImageRouteHandler : IRouteHandler
{
  public IHttpHandler GetHttpHandler(RequestContext requestContext)
  {
    return new ImageHandler(requestContext);
  }
}

Als nächstes erstellen wir die oben genutzte ImageHandler Klasse in der wir das das IHttpHandler Interface implementieren:


public class ImageHandler : IHttpHandler
{
  public ImageHandler(RequestContext context)
  {
    ProcessRequest(context);
  }

  private static void ProcessRequest(RequestContext requestContext)
  {
    var response = requestContext.HttpContext.Response;
    var request = requestContext.HttpContext.Request;
    var server = requestContext.HttpContext.Server;

    var validRequestFile = requestContext.RouteData.Values["filename"].ToString();
    const string invalidRequestFile = "thief.gif";
    var path = server.MapPath("~/graphics/");

    response.Clear();
    response.ContentType = GetContentType(request.Url.ToString());

    if (request.ServerVariables["HTTP_REFERER"] != null &&
        request.ServerVariables["HTTP_REFERER"].Contains("yourdomain.com"))
    {
      response.TransmitFile(path + validRequestFile);
    }
    else
    {
      response.TransmitFile(path + invalidRequestFile);
    }
    response.End();
  }

  private static string GetContentType(string url)
  {
    switch (Path.GetExtension(url))
    {
      case ".gif":
        return "Image/gif";
      case ".jpg":
        return "Image/jpeg";
      case ".png":
        return "Image/png";
      default:
        break;
    }
    return null;
  }

  public bool IsReusable
  {
    get { return false; }
  }
}

Zu Schluss müssen wir diesen neuen Handler mit einer Route in der Global.asax registrieren:


routes.Add("ImagesRoute",
                 new Route("images/{filename}", new ImageRouteHandler()));

Hierbei ist noch wichtig, dass ihr die Route an der passenden Stelle registriert, sodass diese nicht ungewollt von einer anderen Route blockiert wird weil diese auch auf dieses Pattern matcht.

Nun werden alle Requests die auf die Route "images/{filename}" gehen und von einer anderen Domain stammen als eurer eigenen auf eine andere Grafik umgeleitet.

Nun bleibt noch ein kleines Problem, denn wenn das Verzeichnis mit den Bildern in eurem Content Verzeichnis liegt kann immer noch darauf verlinkt werden wenn man den vollen Pfad nimmt, also statt dem virtuellem Pfad

http://localhost/images/myimg.jpg

die URL benutzt unter der tatsächlich alle Bilder liegen:

http://localhost/Content/graphics/myimg.jpg

Dies liegt daran, dass der neue RouteHandler in diesem Fall nicht greift und die Default Route genutzt wird. Am einfachsten kann man dies verhindern wenn man den Zugriff für Unbefugte über die web.config sperrt:


  <location path="Content/graphics">
    <system.web>
      <authorization>
        <allow roles="admin" />
        <deny users="*" />
      </authorization>
    </system.web>
  </location>

Das war dann auch schon, ich nutze gern den zweiten Weg, da dieser mir einfacher und sauberer erscheint. Wenn euch noch andere Möglichkeiten einfallen wie man das anstellen kann dann immer her damit!

17Sep/110

Nice2Know: Attribut-basierende Routen in ASP.NET MVC

Für Routen ist in ASP.NET MVC für gewöhnlich die Global.asax zuständig, so werden hier alle Routen definiert und gemappt. Doch wenn man viele verschiedene Routen nutzen will wird es schnell voll in der eigentlich sehr übersichtlichen Klasse.

Da wäre es doch eigentlich cool wenn wir die Routen direct in unseren Controllern definieren könnten. Genau das können wir mit der Erweiterung AttributeRouting machen.

Installation

Installation über NuGet

Dank NuGet ist die Installation in wenigen Sekunden abgeschlossen und wir können unsere Actions mit Routing-Attributen dekorieren.

Die Attribute sind hierbei sehr einfach gestaltet und bieten uns alles was wir benötigen.


    public class DemoController : Controller
    {
        [GET("Ist/Das/Cool/Oder/Was")]
        public ActionResult Start()
        {
            return View();
        }
    }

Nun muss man nur noch die Attribut-basierten Routen registrieren:


    public static void RegisterRoutes(RouteCollection routes) {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        routes.MapAttributeRoutes(); //--- das wars!

        routes.MapRoute(
            "Default", // Route name
            "{controller}/{action}/{id}", // URL with parameters
            new { controller = "Home", action = "Start",
                id = UrlParameter.Optional } // Parameter defaults
        );
    }

Und fertig! Nun können wir die Seite starten und unsere Route testen:

Das Ergebnis

Das Ergebnis

Die Routen die wir definieren können, beschränken sich nicht darauf, so können diese auch problemlos parametrisiert werden, inklusive Defaultparameter:


    public class DemoController : Controller
    {
        [GET("Artikel/{artikelid}/{version?}")]
        [RouteDefault("artikelid", "120")]
        public ActionResult Start(int artikelid, string version)
        {
            ViewBag.ArtikelId = artikelid;
            ViewBag.Version = version;

            return View();
        }
    }

Hier wird der Parameter artikelid mit einem Defaultwert ausgestattet und der zweite optional gemacht. Das Ergebnis kann sich sehen lasen:

Läuft!

Läuft!

Hier hört das Framework nicht auf, so könnt ihr auch Regular Expressions in die Routen integrieren und auch mehrere Routen an eine Action heften. Die Möglichkeiten sind grenzenlos ;)

Für weitere Infos schaut einfach auf der Projekthomepage vorbei, es lohnt sich!

17Sep/112

Nice2Know: Errorlogging mit ELMAH

Errorlogging? Ist das nicht dieses Zeugs das die ganzen Java Programmierer und Linux Fuzies nutzen werdet ihr euch jetzt denken? Stimmt, aber auch in der .NET Welt ist es sehr nützlich ein Log zu führen und hier gibt es einige Tools für uns Entwickler die für uns diese unschöne Arbeit deutlich ersparen.

Das Tool dass ich euch heute vorstellen möchte ist ELMAH, was für Error Logging Modules and Handlers steht.

Was kann ELMAH? Hier ein Ausschnitt von der Hompage:

  • Logging of nearly all unhandled exceptions.
  • A web page to remotely view the entire log of recoded exceptions.
  • A web page to remotely view the full details of any one logged exception, including colored stack traces.
  • In many cases, you can review the original yellow screen of death that ASP.NET generated for a given exception, even with customErrorsmode turned off.
  • An e-mail notification of each error at the time it occurs.
  • An RSS feed of the last 15 errors from the log

 

Zusammengefasst gesagt schnappt ELMAH sich jede Exception die ihr nicht abgefangen habt und loggt diese für euch im Speicher oder in einer Datenbank und fasst diese auch noch schön zusammen auf einer Übersichtswebseite, in einem RSS Feed oder schickt euch diese direkt per Mail zu.

So könnt ihr jeder Zeit nach der Exception schauen was schiefgelaufen ist und euch den kompletten Stacktrace anschauen und (fast) jeden Yellow Screen of Death nachstellen.

Was mir an diesem Tool besonders gefällt ist die sehr einfach Integration in ein Projekt. Alles was ihr machen müsst ist es dafür zu sorgen dass die DLL in eurem bin-Verzeichnis und einen Handler in eure web.config einzutragen. Nun werden alle eure unbehandelten Exceptions geloggt.

Und es geht sogar noch einfacher, wenn ihr NuGet nutzt werden euch sogar diese Schritte abgenommen, einfach NuGet anwerfen, nach ELMAH suchen und installieren - fertig.

Das Schöne an NuGet ist, dass es nicht nur die Bibliothek herunterlädt sondern auch alle nötigen Einträge für uns anpasst, so werdet ihr nun auch ein paar neue Zeilen in eurer web.config entdecken:

Diese Arbeit blieb uns zum Glück erspart ;) Da nun eigentlich schon alles konfiguriert ist können wir fröhlich ein paar Fehler erzeugen:

Ich habe hier also eine URL aufgerufen für die kein Controller und keine View bestimmt werden konnte. Dass wir hier so “viele” Informationen angezeigt bekommen liegt daran, dass wir die Seite lokal aufrufen, würden wir das ganze von einem anderem System machen würden uns noch weniger Informationen zur Verfügung stehen.

Nun wollen wir mal gucken, was ELMAH für uns aufgezeichnet hat, das können wir machen, in dem wir diese Seite aufrufen: /elmah.axd

Alle aufgetretenen Exceptions für uns übersichtlich dargestellt. Wenn Bedarf besteht kann man natürlich auch tiefer bohren und die Details aufklappen:

Hier hat man nun den vollen Stacktrace und viele weitere Informationen wie z.B. die Servervariablen. Eine sehr coole Sache wie ich finde, da ihr nun auch von unterwegs eure Fehler untersuchen könnt.

Falls ihr nicht wollt, dass jeder eure Exceptions sehen kann ist dies natürlich auch möglich.

UPDATE: Ich habe hier die normale Version von ELMAH genutzt, für ein MVC Projekt würde ich aber ELMAH.MVC empfehlen (Ebenfalls auf NuGet verfügbar). Dieses integriert sich besser in eine MVC Umgebung da es einen AdminController anlegt und somit über /Admin/Elmah erreichbar ist.

ELMAH gibt es übrigens schon eine halbe Ewigkeit aber ich (Langschläfer) bin erst vor ein paar Wochen drüber gestolpert. Wie schaut es bei euch aus? Nutzt ihr ELMAH?

10Mai/111

Benutzerregistrierung mit ASP.NET MVC und jQuery Teil 2

Im ersten Teil haben wir die Ajax-Funktionalität mit Hilfe von jQuery “zu Fuß” implementiert und haben nur die einfachsten Mittel verwendet. In diesem zweiten Teil wollen wir das nun mit Hilfe des ASP.NET MVC3 Frameworks implementieren, welches uns einiges an Arbeit abnimmt.

Das schöne an der dritten Version des MVC Frameworks ist, dass Microsoft hier schon einige helfende Elemente zum Validieren von Clientangaben eingebaut hat, die wir oft mit nur einer kleinen Zeile Code oder einem Attribut aktivieren können.

Fangen wir also mit unserem Model an und erweitern es um die neuen Attribute die uns das Framework zur Verfügung stellt:


public class RegisterModel2 {

    [Required(AllowEmptyStrings = false,
                ErrorMessage = "Bitte geben Sie einen Benutzernamen an!")]
    [DisplayName("Benutzername")]
    [Remote("ValidateUsername", "Validation")]
    public String UserName { get; set; }

    [Required(AllowEmptyStrings = false,
                ErrorMessage = "Bitte geben Sie eine Emailadresse an!")]
    [DisplayName("E-Mail Adresse")]
    [Remote("ValidateEmail", "Validation")]
    public String UserMail { get; set; }

    [Required(AllowEmptyStrings = false,
                ErrorMessage = "Bitte geben Sie ein Passwort an!")]
    [DisplayName("Passwort")]
    [DataType(DataType.EmailAddress)]
    [Remote("ValidatePassword", "Validation")]
    public String UserPass { get; set; }

    [Required(AllowEmptyStrings = false,
                ErrorMessage = "Bitte wiederholen Sie ihr Passwort!")]
    [Compare("UserPass", ErrorMessage="Die Passwörter stimmen nicht überein!")]
    [DisplayName("Passwort wiederholen")]
    public String UserPass2 { get; set; }
}

 

Wie man sieht sind nun einige Attribute dazugekommen, die Eigenschaften der Klasse an sich haben sich aber nicht verändert! Aber mal langsam, was bedeuten diese Attribute eigentlich?

  • Required
    • Markiert die Eigenschaft als Pflichtfeld. Durch setzen dieses Attributs wird beim Absenden des Formulars automatisch geprüft ob diesem Feld ein Wert zugewiesen wurde, falls nicht wird eine Fehlermeldung generiert.
    • Durch die Option AllowEmptyStrings = false sorgen wir dafür, dass auch Werte die nur als Leerzeichen bestehen ebenfalls Fehler auslösen.
    • Mit dem Setzen der ErrorMessage Eigenschaft können wir eine Eigene Fehlermeldung definieren, die statt der Standardmeldung angezeigt wird. Lässt man diese Eigenschaft weg wird eine Meldung generiert die ca. so ausschaut: “Das Feld "FELDNAME" ist erforderlich.”
  • DisplayName
    • Dieses Attribut haben wir auch schon in dem Letzten Teil benutzt. Dieses sorgt dafür dass wir den Namen für das Eingabefeld, dass der Benutzer später im Browser zu sehen bekommt bereits im Model definieren können.
  • Remote
    • Durch dieses Attribut definieren wir welche Methode und welcher Controller für das Validieren der Eigenschaft verantwortlich ist. Erst wird die Action und als zweiter Parameter der Controller angegeben. Wenn der Benutzer später Eingaben in das Textfeld tätigt, wird diese Action aufgerufen und der eingegebene Wert als Parameter übergeben, sehr ähnlich wie wir es in Teil 1 gemacht haben, aber später mehr dazu.
  • DataType
    • Damit kann man den Inhalt bestimmen was einem beim Validieren helfen kann.
  • Compare
    • Mit diesem Attribut können wir angeben, dass diese Eigenschaft den gleich Wert haben muss wie eine andere. Dies wird dann automatisch von jQuery überprüft, somit müssen wir nicht mehr machen als dieses Attribut zu setzen.
    • Als Parameter übergeben wir den Namen der Eigenschaft mit der der Wert verglichen werden soll und, als zweiten setzen wir eine eigene Fehlermeldung damit eine vernünftige Fehlermeldung angezeigt wird.

Damit haben wir unser Model fertiggestellt, nun schauen wir uns an was wir an unserer View verändern müssen.

Die gute Nachricht ist, dass wir den kompletten JavaScript/jQuery Teil streichen können, da das für uns alles automatisch geregelt wird, so sieht nun unsere View aus:

 


    @using (Html.BeginForm("Submit", "Validation")) {
        <table border="1">
            <tr><td>@Html.LabelFor(model => model.UserName):</td>
                <td>@Html.TextBoxFor(model => model.UserName)</td>
                <td>@Html.ValidationMessageFor(model => model.UserName)</td>
            </tr>
            <tr><td>@Html.LabelFor(model => model.UserMail):</td>
                <td>@Html.TextBoxFor(model => model.UserMail)</td>
                <td>@Html.ValidationMessageFor(model => model.UserMail)</td>
            </tr>
            <tr><td>@Html.LabelFor(model => model.UserPass):</td>
                <td>@Html.TextBoxFor(model => model.UserPass)</td>
                <td>@Html.ValidationMessageFor(model => model.UserPass)</td>
            </tr>
            <tr><td>@Html.LabelFor(model => model.UserPass2):</td>
                <td>@Html.TextBoxFor(model => model.UserPass2)</td>
                <td>@Html.ValidationMessageFor(model => model.UserPass2)</td>
            </tr>
            <tr><td> </td>
                <td><input id="submit_form_button" type="submit"
                            value="Registrierung abschicken" /></td>
                <td> </td>
            </tr>
        </table>
    }

 

Wenn ihr euch den Code anschaut, werdet ihr feststellen, dass sich eigentlich nicht getan hat. Das Einzige was sich verändert hat ist dass nun das Span in dem wir im letzten Teil die Fehler ausgegeben haben verschwunden ist und stattdessen

@Html.ValidationMessageFor(model => model.xxxxx)

aufgetaucht. Wie man sich auch schon von dem Namen ableiten kann wird hier eine Validierungsnachricht angezeigt, also mit anderen Worten die Fehlermeldung die bei der Validierung dieses Feldes entsteht. Diese Fehlermeldungen haben wir zum Teil schon über die Attribute im Model definiert.

Das wars auch schon mit Änderungen. Smiley super oder? Wir haben nun einen Haufen Code rausgeworfen, ein paar Attribute eingefügt und nicht eine Zeile JavaScript geschrieben - perfekt Zwinkerndes Smiley

Aber noch sind wir nicht ganz fertig, denn wir haben nun gar nicht die Regeln für die Validierung des Benutzernamen, der Emailadresse und des Passworts implementiert.

Wenn ihr aufgepasst habt werdet ihr euch daran erinnern, dass wir das Attribut [Remote] verwendet haben und dort als Parameter den Namen einer Action angaben, an die die Informationen zur Validierung gesendet werden sollten.

Diese Actions müssen wir nun natürlich in unserem Validation Controller implementieren, zu unserem Glück unterscheiden sich diese Methoden nur minimal von denen die wir bereits im letzten Teil erstellt haben:


public ActionResult ValidateUsername(string UserName) {
    //Wenn in unserer "Datenbank" der Name bei einem anderen Benutzer Auftaucht
    if (new UserDatabase().Users.Where(u => u.Username.Equals(UserName)).ToList().Count > 0) {
        //Eine Fehlermeldung zurückgeben
        return Json("Dieser Benutzername ist schon vergeben", JsonRequestBehavior.AllowGet);
    }

    //Wenn der Benutzername kürzer als 5 Zeichen ist ebenfalls Fehler ausgeben
    if (UserName == null || UserName.Length < 5) {
        //return "Der Benutzername ist zu Kurz!";
        return Json("Der Benutzername ist zu kurz!", JsonRequestBehavior.AllowGet);
    }

    //Falls es nichts zu meckern gibt geben wir true zurück
    return Json(true, JsonRequestBehavior.AllowGet);
}

 

Was ist passiert? Die Logik der Funktion ist gleich geblieben, lediglich der Rückgabetüp und die Rückgabemethode hat sich geändert. Wir geben nun ein ActionResult statt eines einfachen Strings zurück. Dazu rufen wir die Methode Json auf der wir als Parameter die Daten übergeben die übertragen werden sollen und als zweites erlauben wir GET Aufrufe.

Die Antwort die dadurch erzeugt wird wird automatisch auch in ein Format umgewandelt die jQuery versteht. da wir in diesem Fall aber nur ein Boolean oder einen String übergeben ist dies nicht nötig.

Wenn wir einen String ausgeben wird das als Ausgabe für die Fehlermeldung genutzt. Alternativ können wir auch ein false ausgeben, dann wird die Standardfehlermeldung angezeigt, die nicht allzu schön ist. Durch die Angabe von true sagen teilen wir jQuery auf der Clientseite mit, dass kein Fehler aufgetreten ist und dass es die eventuell angezeigte Fehler ausblenden soll.

Die anderen zwei Validierungsmethoden müssen genauso geändert werden um problemlos mit dem [Remote] Attribut genutzt zu werden wodurch wir den Vorteil erhalten, dass wir kein JavaScript Code schreiben müssen, alles wird von den Frameworks automatisch geregelt.

An dieser Stelle lohnt es sich mal anzuschauen was da eigentlich generiert wird für uns. Starten wir also unsere MVC Applikation und gucken mal in den Quelltext:


<td><label for="UserName">Benutzername</label>:</td>
<td><input data-val="true"
		data-val-remote="&amp;amp;amp;#39;Benutzername&amp;amp;amp;#39; is invalid."
		data-val-remote-additionalfields="*.UserName"
		data-val-remote-url="/Validation/ValidateUsername"
		data-val-required="Das Feld &amp;amp;amp;quot;Benutzername&amp;amp;amp;quot; ist erforderlich."
		id="UserName" name="UserName"
		type="text"
		value="" />
</td>
<td><span class="field-validation-valid"
		data-valmsg-for="UserName"
		data-valmsg-replace="true"></span>
</td>

Oben ist der Ausschnitt zu sehen, der für das Benutzername-Eingabefeld verantwortlich ist inklusive dem dazugehörigen Label und dem Validierungstext.

Auffällig ist, dass kein JavaScript generiert wurde, sondern das Input-Element mit zusätzlichen Tags versehen wurde, die aber nur für jQuery von Bedeutung sind. Andere Applikationen oder Frameworks werden dadurch also nicht beeinflusst, diese ignorieren einfach diese für sie unbekannte Attribute.

Wenn man die Attribute etwas genauer betrachtet wird man einiges aus unserem Model wiederfinden, wie zum Beispiel unsere dort definierte Fehlermeldung.

Nun bleibt nur noch eine Kleinigkeit zu tun, nämlich das nötige CSS zu schreiben dass mit der jQuery Validierung zusammenspielt und die nötigen JavaScript Dateien zu importieren.

Fangen wir mit dem Importieren der JavaScript Bibliotheken an. Wenn ihr ein neues MVC3 Projekt anlegt habt ihr schon alle Dateien die nötig sind bereits in eurem Scriptordner. Öffnet die “_Layout.cshtml” und fügt (falls noch nicht vorhanden) folgende Imports hinzu:


<script src="@Url.Content("~/Scripts/jquery-1.4.1.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>

Diese Imports werden nun durch diese Mastervorlage in jede View eingebunden. Natürlich könnt ihr diese Imports auch explizit nur in die View schreiben in der diese auch benötigt werden, das wäre sogar vorteilhafter denke ich.

Zu guter Letzt kümmern wir uns um das CSS. Auch hier generiert euch Visual Studio das nötige CSS wenn ihr ein neues MVC Projekt anlegt, auch wenn ihr als Vorlage ein leeres MVC Projekt wählt. In dem Ordner Content werdet ihr eine Datei namens Site.css finden in der die CSS Klassen für die Validierung stehen:


/* Styles for validation helpers
-----------------------------------------------------------*/
.field-validation-error
{
    color: #ff0000;
}

.field-validation-valid
{
    display: none;
}

.input-validation-error
{
    border: 1px solid #ff0000;
    background-color: #ffeeee;
}

.validation-summary-errors
{
    font-weight: bold;
    color: #ff0000;
}

.validation-summary-valid
{
    display: none;
}

jQuery greift auf diese Klassen zurück um das Aussehen der Eingabefelder entsprechend dem Validierungsergebnis anzupassen. Hier könnt ihr nun eure Eigenen Änderungen vornehmen und die Visualisierung euren Wünschen anpassen.

Ich habe hier noch, um das Beispiel aus Teil 1 nicht aus den Augen zu verlieren die CSS Klasse etwas erweitert um das Aussehen anzugleichen:


.input-validation-error
{
    border: 1px solid #ff0000;
    background-color: #ffeeee;
    background-image: url("../Grafik/cancel.png");
    background-position: right;
    background-repeat: no-repeat;
}

Wenn man die Applikation nun startet funktioniert das Beispiel dem aus Teil 1 sehr ähnlich:

image

Damit haben wir es eigentlich schon geschafft. Zum Schluss noch ein kleiner Hinweis. Natürlich ist dieser Weg um einiges einfacher, aber es gibt auch einen kleinen Haken, nämlich dass das Framework begrenzt ist. Das bedeutet, dass man nicht alles darüber schnell und ohne selber Code zu schreiben lösen kann, viele Anforderungen müssen immer noch von Hand oder mit Hilfe von anderen Frameworks implementiert werden.

Das erweiterte Demoprojekt aus Teil 1 gibts hier: Download [VS2010 c#]

<< Teil 1

kick it on dotnet-kicks.de

 

8Mai/114

Benutzerregistrierung mit ASP.NET MVC und jQuery Teil 1

Wer heute Webanwendungen erstellt kommt einfach nicht drumherum JavaScript zu verwenden um dem Benutzer zb. die Eingabe von Daten in ein Formular zu erleichtern und zB. Hinweise während der Eingabe anzuzeigen.

Leider ist JavaScript bei vielen nicht wirklich beliebt und die meisten versuchen wann immer es geht darauf zu verzichten, und das auch aus guten Gründen, denn ähnlich wie mit dem HTML Standard arbeiten die verschiedenen Browser in einigen Bereichen etwas eigenwillig, das kann einen schon mal zur Verzweifelung treiben.

Das haben sich auch viele andere gedacht und so gibt es inzwischen viele Frameworks die dem Entwickler viel Arbeit abnehmen und sich um diese fiesen Sachen wie die Kompabilität zu Browsern kümmern. In meinem Beispiel hier möchte ich euch das JavaScript Framework jQuery vorstellen.

Warum jQuery?

jQuery ist inzwischen in der Version 1.5.1 verfügbar und ist kompatibel zu allen Browsern, desweiteren ist die Community sehr groß und es existieren hunderte von Plugins die ich nutzen könnt. Aber die wirklich guten Gründe sind, dass es über eine sehr sehr gute Dokumentation verfügt, alle Browser inklusive des IE9 unterstützt und offiziell von Microsoft supportet wird. Wenn ihr also beispielsweise ein neues ASP.NET (MVC) Projekt erstellt werdet ihr feststellen, dass ihr im Scripts-Ordner bereits die jQuery Scripte hinterlegt habt.

Was macht dieses Framework eigentlich?

jQuery wie der Name es schon sagt zeigt seine ganze Stärke in der Auswahl bzw. der Selektion von Webseitenelementen im DOM, so kann man mit einfachen Einzeilern ganze Webseiten-Bereiche modifizieren. Außerdem bietet jQuery Funktionen die man häufig nutzt wie zB. Asynchrone Ajax aufrufe oder Animationen von Feldern. Aber gut kommen wir zu unserem Beispiel.

Unser Beispiel

Als Beispiel möchte ich hier ein einfaches Registrierungsformular erstellen, dass wir dann mit jQuery aufwerten wollen. Dabei möchte ich hier den manuellen Weg gehen und nicht die in ASP.NET MVC3 integrierten Methoden nutzen, eventuell können wir ja ein einem zweiten Teil dann den anderen Weg darstellen.

Beginnen wir erstmal mit dem Model. Da wir unsere Registrierung simpel halten wollen muss der Benutzer nur drei Angaben machen, nämlich seinen Namen, Email Adresse und ein Passwort. Normalerweise würden wir unser model hier ca so gestalten:


public class RegisterModel {

    [Required]
    [DisplayName("Benutzername")]
    [Remote("CheckUserName", "Validation")]
    public String UserName { get; set; }

    [Required]
    [DisplayName("E-Mail Adresse")]
    [DataType(DataType.EmailAddress)]
    [Remote("CheckUserEmail", "Validation")]
    public String UserMail { get; set; }

    [Required]
    [DisplayName("Passwort")]
    [Remote("CheckUserNPassword", "Validation")]
    public String UserPass { get; set; }

    [Required, Compare("UserPass")]
    [DisplayName("Passwort wiederholen")]
    public String UserPass2 { get; set; }
}

Da wir das aber selber machen wollen und teils clientseitig validieren wollen schwächen wir das mal etwas ab und nehmen alles raus bis auf das DisplayName Attribut:


public class RegisterModel {
    [DisplayName("Benutzername")]
    public String UserName { get; set; }

    [DisplayName("E-Mail Adresse")]
    public String UserMail { get; set; }

    [DisplayName("Passwort")]
    public String UserPass { get; set; }

    [DisplayName("Passwort wiederholen")]
    public String UserPass2 { get; set; }
}

So, nachdem wir das Model nun fertig haben, bauen wir das Projekt ein Mal und erstellen unsere View. Hier habe ich eine simple Tabelle angefertigt, die die nötigen Form-Elemente beinhaltet, die der Benutzer ausfüllen soll:


<div id="register_form">

<div id="headline">Registrierung</div>

�
<form id="registration_form" action="/Register" method="post">

<table border="1">
<tbody>
<tr>
<td>@Html.LabelFor(model => model.UserName):</td>
<td>@Html.TextBoxFor(model => model.UserName)</td>
<td><span id="UserName_error"> </span></td>
</tr>
<tr>
<td>@Html.LabelFor(model => model.UserMail):</td>
<td>@Html.TextBoxFor(model => model.UserMail)</td>
<td><span id="UserMail_error"> </span></td>
</tr>
<tr>
<td>@Html.LabelFor(model => model.UserPass):</td>
<td>@Html.TextBoxFor(model => model.UserPass)</td>
<td><span id="UserPass_error"> </span></td>
</tr>
<tr>
<td>@Html.LabelFor(model => model.UserPass2):</td>
<td>@Html.TextBoxFor(model => model.UserPass2)</td>
<td><span id="UserPass2_error"> </span></td>
</tr>
<tr>
<td></td>
<td><input id="submit_form_button" type="submit" value="Registrierung abschicken" /></td>
<td></td>
</tr>
</tbody>
</table>

�
</form>

�
</div>

Hier benutze ich die neue Razor Syntax von ASP.NET MVC3 falls ihr damit noch nicht vertraut seid könnt ihrhier mal gucken.

So sieht das Beispielformular aus

Die erste Spalte enthält hier jeweils die Beschreibung des Feldes, die zweite das Input-Element und die Dritte ist für die Anzeige von Fehlern zuständig, zu Beginn aber leer!

Der jQuery Part

So weit so gut, nun haben wir eigentlich schon alles was wir benötigen, und wenn wir nun nicht die Absicht hätten JavaScript zu benutzen wären wir an dieser Stelle schon fertig, müssten nur noch den Controller Part implementieren und könnten alles zu den Akten legen. Aber wir wollen dem Benutzer hier eine möglichsts angenehme Erfahrung bieten, denn vielleicht habt ihr es schon selbst erlebt und musstet euch auf einer Seite anmelden wo die Anmeldung ein Krampf war, das kann einem schon mal den einen oder anderen User kosten!

Was wollen wir hier nun also verbessern?

  • Wenn der Benutzer einen Benutzernamen eingibt prüft das System im Hintergrund automatisch ob dieser Name schon vergeben ist und markiert das Eingabe Feld entsprechend.
  • Nach der Eingabe der Email-Adresse wird diese automatisch geprüft nach Format und Verfügbarkeit und der Benutzer bekommt signalisiert ob damit alles in Ordnung ist, natürlich alles im Hintergrund
  • Wenn der Benutzer sein Passwort wählt prüften wir ob dessen Stärke für uns ausreicht und ob beide Passwortfelder auch das gleiche Passwort beinhalten
  • Der Absenden-Button wird erst anklickbar, nachdem alle Felder so ausgefüllt sind wie wir es uns vorstellen

Alles das können wir dank jQuery sehr einfach erreichen. Fangen wir mal vorne mit Punkt 1 an.

Erst ein mal zu dem allgemeinen Ablauf, wie soll das Ganze funktionieren?

  1. Also der Benutzer tippt seinen Wunschnamen ein,
  2. und wechselt aus dem Benutzername-Eingabefeld.
  3. Nun soll unsere Webseite den eingegebenen Wert nehmen, und diesen an den Server senden
  4. Der Server prüft den Namen auf Verfügbarkeit oder Form und Verbotene Zeichen etc
  5. Und sendet eine Information zurück. Diese Information ist entweder ein Fehler oder eine Erfolgsmeldung
  6. Je nachdem ob ein Erfolg oder ein Fehler vermeldet wird wird eine Fehlermeldung angezeigt und das Eingabefeld markiert

Klingt doch eigentlich ganz logisch! Fangen wir an. Erst einmal benötigen wir die jQuery Scriptdatei, diese bekommen wir direkt auf der Startseite von www.jquery.com Rechts oben auf der Startseite könnt ihr zwischen der Production und der Development Version wählen. Der unterschied besteht nur darin, dass die Production Version stark komprimiert ist und somit weniger Traffic verursacht, wenn ihr recht frisch seit was jQuery und javascript angeht solltet ihr euch die Development Version laden, da diese besser zu debuggen ist!

Nachdem ihr das Script geladen habt müssen wir das in unser Projekt einbinden. Zieht die js-Datei einfach aus dem Windows Explorer per Drag & Drop in euer Scripts-Ordner im Projekt Explorer. Nun fügen wir noch die Referenz auf die Datei hinzu, das machen wir am besten in der _Layout Datei die im Shared-Verzeichnis des View Verzeichnisses liegt. Hier ist wahrscheinlich schon ein Verweis auf ein jQuery Script vorhanden, ihr müsst nur noch den Pfad anpassen:


<script src="@Url.Content("~/Scripts/jquery.1.5.1.min.js")" type="text/javascript"></script>

Diese _Layout Datei wird automatisch in alle unsere Views eingebunden (zur Laufzeit), deswegen müssen wir den Verweis  nur an dieser Stelle einfügen, praktisch oder?

Nachdem das geschafft ist können wir uns dem eigentlichen Teil widmen. Wechseln wir also wieder zurück zu unserem Login Formular und machen uns an unseren Punkt 1.

Bevor wir starten möchte ich hier nochmal kurz erwähnen, dass das ein Anfänger Tutorial ist und wir die Kommunikation mit dem Server sehr einfach gestalten werden, eventuell werde ich dann noch einen weiteren Teil machen in dem wir die Kommunikation mit JSON realisieren.

Fangen wir an

JQuery ist nichts anderes als Javascript, ihr habt sicherlich auch schon Javascript Dateien erstellt und diese dann in eure Webseiten eingebunden, hier machen wir nichts anderes, ihr könnt ja auch einfach in die jQuery Datei reinschauen, es ist "nur" javascript.

Wenn wir Funktionen von jQuery benutzen wollen können wir das tun in dem wir das Dollarzeichen benutzen "$" oder jQuery ausschreiben, so funktioniert beides:


    $.ajax(...);
    jQuery.ajax(...);

Ich nutze nur die $-Schreibweise, einfach nur weil es kürzer ist, es ist jedoch euch überlassen was ihr lieber mögt.

Mit jQuery ist sehr einfach Seitenelemente im DOM auszuwählen, so genügt eine einfache Angabe der Klasse, ID oder des Elementen-Typs um diese auszuwählen. Hier ein paar Beispiele:


<script type="text/javascript">
    //Wählt das Element mit der ID username aus und setzt die Hintergrundfarbe auf rot
    $('#username').css('background-color', 'red');

    //Wählt ALLE Elemente mit der Klasse link aus und setzt die Hintergrundfarbe auf rot
    $('.link').css('background-color', 'red');

    //Wählt ALLE Input-Elemente aus und setzt deren Hintergrundfarbe auf rot
    $('input').css('background-color', 'red');
</script>

Das obere Beispiel zeigt wie wir mit mir einer Zeile eine ganze menge Elemente bearbeiten können, die ganze Arbeit erledigt jQuery für uns im Hintergrund. Hier habe ich jQuerys methode "css" benutzt, diese erlaubt es uns eine bestimmte CSS-Eigenschaft eines Elements zu setzten oder zu bearbeiten.

Das ist eigentlich schon das Grundkonzept von jQuery, man wählt sich die Elemente aus mit denen man etwas anstellen will und führt einige Modifikationen an ihnen durch.

Weiterhin bietet uns jQuery auch die Möglichkeit Events anzulegen und zu behandeln, was für uns in Hinsicht auf unsere Aufgaben gleich noch wichtig wird. Aber zunächst ein kleines Beispiel:


$('.my_button').click(function () {
	$('.my_button').toggleClass('some_css_class');
});

Dieser Dreizeiler hat es schon ganz schön in sich, denn hier geschieht eine ganze Menge. Als erstes suchen wir uns das Element mit der Klasse my_button und fügen diesem mit der Click-Methode ein Click-Event hinzu. Als Parameter übergeben wir hier auch gleich die Methode, die ausgeführt werden soll, wenn der Benutzer auf dieses Element klickt.

Innerhalb der Methode wählen wir dann dieses Element erneut aus und ändern dessen Klasse mit der toggleClass Methode. Diese Methode hat aber eine Sonderheit, nämlich dass sie sich merkt welche Klasse diesem Element zugewiesen war bevor darauf geklickt wurde, so wird bei einem erneuten Klick die Klasse wieder zurückgetauscht zu der ersten Klasse.

Das ändern der Klassen von Elementen ist sehr wichtig, denn so kann man sehr einfach das Aussehen von diesen ändern. Wenn der Benutzer seinen Namen eingegeben hat soll er Feedback bekommen ob dieser Name ok ist, das soll so realisiert werden:

Ablauf der Visualisierung

Eingabe -> Überprüfung (Auf dem Server) -> Anzeige des Ergebnisses. Dank der kleinen Icons im Textfeld weiß der Benutzer sofort wie es um seinen Namen steht und er kann auch erkennen, dass die Webseite gerade beschäftigt ist durch den kleinen Kreisel in Schritt 2. Und falls es nicht klappt weiß der Benutzer sofort woran es gelegen hat, da er eine genaue Fehlermeldung bekommt. Und das alles geschieht ohne die Seite neuladen zu müssen nebenbei.

Das Nachladen der benötigten Informationen im Hintergrund nennt man Ajax, dabei ist das keine neue Technologie, sondern einfach nur eine Art einen Request im Hintergrund über JavaScript abzusetzen.

Da wir oben bereits unser Formular angefertigt haben, über das der Benutzer sich registrieren soll können wir uns nun etwas um die Serverseite kümmern und erstellen die nötigen Actions in dem Validation Controller der für die Überprüfung der Vom Benutzer eingegebenen Werte zuständig sein wird:


public class ValidationController : Controller
{
    //
    // GET: /Validation/CheckUsername/[name]

    public String CheckUsername(string username)
    {
        //Wenn in unserer "Datenbank" der Name bei einem anderen Benutzer Auftaucht
        if (new UserDatabase().Users.Where(u => u.Username.Equals(username)).ToList().Count > 0) {
            //Eine Fehlermeldung zurückgeben
            return "Dieser Benutzername ist schon vergeben";
        }

        //Wenn der Benutzername kürzer als 5 Zeichen ist ebenfalls Fehler ausgeben
        if(username.Length < 5){
            return "Der Benutzername ist zu Kurz!";
        }

        //Falls es nichts zu meckern gibt geben wir "ok" aus
        return "ok";
    }
}

In diesem Controller habe ich eine Action Methode definiert, die einen string zurück gibt statt einem ActionResult, dadurch wird der Text den wir im Returnstatement abgeben direkt an den Browser weitergereicht ohne Umweg über eine View die wir uns dadurch sparen.
Die Methode selbst macht nichts spannendes, zu erst wird hier die UserDatabase nach Usern durchsucht die den selben Namen haben und bei einem Treffer eine Fehlermeldung ausgegeben und als zweites führe ich eine Prüfung darauf durch ob der Benutzername zu kurz ist. - Falls alle Kriterien passen geben wir ein "ok" zurück.
Die UserDatabase Klasse ist übrigens nur ein Dummy Repository, dass für uns eine Datenbank simuliert:


public class UserDatabase {

    public List Users;

    public UserDatabase() {
        Users = new List(){
            new User(){Username = "Bernd", Useremail = "bernd@gmx.de"},
            new User(){Username = "Bill", Useremail = "bill@microsoft.de"}
        };
    }
}
public class User {
    public string Username { get; set; }
    public string Useremail { get; set; }
}

Nun haben wir eine sehr simple Überprüfung des Benutzernamen eingebaut. Machen wir das gleich noch mal für die Email Adresse und das Passwort:


public string CheckEmail(string email) {
    //Wenn in unserer "Datenbank" die Emailadresse bei einem anderen Benutzer Auftaucht
    if (new UserDatabase().Users.Where(u => u.Useremail.Equals(email)).ToList().Count > 0) {
        //Eine Fehlermeldung zurückgeben
        return "Diese Emialadresse ist schon vergeben";
    }

    return "ok";
}

public string CheckPassword(string password) {
    //Unser einziges Kriterium für das Passwort ist dass es mindestens 4 Zeichen lang sein muss
    if (password.Length < 4) {
        return "Das Passwort ist zu kurz!";
    }

    return "ok";
}

Absolut nichts kompliziertes wie ihr seht. Natürlich halte ich hier die Methoden und Aktionen sehr simpel um dies verständlicher zu machen, in einem echten Projekt würde man hier natürlich anders vorgehen. Das werden wir dann im zweiten Teil besprechen.

Da unser Backend nun bereit ist müssen wir uns jQuery kümmern und unserem Formular beibringen im Hintergrund mit dem Server zu kommunizieren.


$(document).ready(function () {

    $('#UserName').change(function () {
        //Diese Aktion wird ausgeführt wenn sich der Test im Username
        //Textfeld ändert

        //Style klassen entfernen und die validierungsklasse einfügen
        $('#UserName').removeClass('validation_ok validation_error');
        $('#UserName').addClass('validating');

        var username = $('#UserName').val();
        $.ajax({ url: '/Validation/CheckUserName/' + username,
            success: function (data) {
                if (data == "ok") {
                    //Die Daten wurden vom Controller akzeptiert
                    $('#UserName').removeClass('validating');
                    $('#UserName').addClass('validation_ok');
                    $('#UserName_error').html('');
                } else {
                    //Fehlermeldung vom Server ausgeben
                    $('#UserName').removeClass('validating');
                    $('#UserName').addClass('validation_error');
                    $('#UserName_error').html(data);
                }
            }
        });
    });
});

Gehen wir den Code mal gemeinsam durch, wir beginnen mit der jQuery Funktion "ready", diese wird automatisch ausgeführt sobald der Browser die komplette Seite geladen hat. Als Parameter übergeben wir eine anonyme Funktion, die daraufhin direkt ausgeführt wird.

Innerhalb dieser Funktion (Zeile 3) benutzen wir die jQuery Selektoren um die Textbox mit der id "UserName" zu schnappen und hängen dieser ein "change" Event an. Dieses Event wird immer ausgeführt wenn sich der Inhalt der Textbox ändert. An dieser Stelle wollen wir eingreifen und die geänderten Daten zum Server senden, damit er diese prüfen kann.

In Zeile 8 und 9 benutzen wir die "removeClass" und "addClass" Funktionen von jQuery um der "UserName" Textbox CSS Klassen hinzuzufügen oder wegzunehmen. So fügen wir in Zeile 9 die CSS Klasse hinzu, durch die die TextBox das Animations-GIF erhält, das dem Benutzer anzeigt, dass die Eingaben überprüft werden.

Der Spannende Teil beginnt erst in Zeile 11, denn hier lesen wir den Benutzernamen aus der Textbox und senden diesen dann über die "ajax" Methode von jQuery zum Server. Diese Methode von jQuery ist sehr mächtig und man kann hier dementsprechend diverse Parameter definieren, aber wir benutzen hier stattdessen nur die einfachste Variante, und diese benötigt nur die URL an die der Request gesendet werden soll und eine Referenz auf eine Funktion die ausgeführt werden soll wenn alles erfolgreich verlaufen ist.

Die URL selbst haben wir durch die Namen unserer Controller im Backend schon vergeben, denn wir sprechen hier den Validation-Controller an und rufen die CheckUserName-Methode auf, der wir den eingelesenen Namen als Parameter übergeben. Heraus kommt eine URL wie z.B. diese hier: localhost/Validation/CheckUserName/Bill.

Nachdem der Request nun angesendet wurde und erfolgreich eine Antwort empfangen wurde, wird unsere anonyme Funktion ausgeführt, die das vom Server zurückgegebene Ergebnis auswertet. Im Fall dass der Server ein "ok" zurückgibt wird ein grüner Haken im Textfeld angezeigt und ansonsten ein rotes "x" und die Fehlermeldung in nebenstehenden span ausgegeben. (Zeile 23)

Schauen wir uns doch mal an ob alles so funktioniert wie geplant:

Notiz des Autors: Bei dieser Abbildung wurde kein Wert auf optische Schönheit gelegt

Wie man sieht wurde der Benutzername "Bernd" als fehlerhaft markiert, da dieser bereits in unserer "Datenbank" auftaucht, die Emailadresse hingegen ist ok, da sie noch nicht benutzt wird.

Die jQuery Implementierung für die restlichen  Textfelder kann eigentlich 1 zu 1 übernommen werden, es sollten lediglich die Parameter ausgetauscht werden. Die einzige kleine Besonderheit stellt die Prüfung des Passworts dar, ob die beiden Felder gleich sind, das kann man nämlich komplett clientseitig regeln, ohne die Daten zum Server zu senden:


$('#UserPass2').change(function () {
    //Diese Aktion wird ausgeführt wenn sich der Text im Passwort
    //Textfeld ändert

    //Style klassen entfernen
    $('#UserPass2').removeClass('validation_ok validation_error');

    var pass = $('#UserPass').val();
    var pass2 = $('#UserPass2').val();

    if (pass == pass2) {
        //Die Daten wurden vom Controller akzeptiert
        $('#UserPass2').addClass('validation_ok');
        $('#UserPass2_error').html('');
    } else {
        //Fehlermeldung ausgeben
        $('#UserPass2').addClass('validation_error');
        $('#UserPass2_error').html('Die Passwörter sind nicht gleich');
    }
});

Im Grunde sind wir nun fertig und haben auf einfachste Weise unser Registrierungsformular aufgewertet und dem User vielleicht ein paar Nerven gespart.

Ich möchte hier noch mal hinweisen, dass man in einem Realprojekt nicht so handeln würde, da es viel zu umständlich und nicht wirklich gut wartbar ist. Dieser Beitrag soll lediglich die Grundlagen erklären und zeigen wie man so etwas zu Fuß und mit den grundlegendsten Mitteln erstellen kann.

Im nächsten Teil werden wir dann die MVC3 eigenen Features benutzen die uns diese Aufgaben um einiges erleichtern und zu einem Großteil automatisch funktionieren.

Das Demo-Projekt könnt ihr hier laden: Download [VS2010 c#]

Teil 2 lesen >>
kick it on dotnet-kicks.de

5Apr/118

Unterlagen zu meinem ‘ASP.NET MVC 3 von 0 an’ Vortrag

Gestern am 04.04.2011 habe ich für die .NET Online Usergroup einen Vortrag für ASP.NET MVC 3 Einsteiger gegeben, vielleicht wart ihr sogar dabei.

Da schnell die Frage nach den Folien und dem Beispielcode der während der Präsentation entstand aufkam, möchte ich diese hiermit nachliefern.

Installation

In meinem Vortrag ging ich nicht darauf ein, wie man ASP.NET MVC installiert, dies will ich hiermit nachliefern. Die Installation erfolgt schnell und einfach über den ASP.NET MVC Installer den ihr auf der ASP.NET MVC Homepage bekommt oder über diesen Direktlink. Die Installation an sich ist nicht weiter erwähnenswert ;-)
Nach der Installation werden ihr die Projektvorlage in Visual Studio vorfinden.

Kostenlos ASP.NET MVC Entwickeln

Falls ihr keine Visual Studio Lizenz besitzt könnt ihr den Visual Web Developer benutzen um MVC zu entwickeln:
http://www.microsoft.com/germany/express/products/web.aspx

Aufzeichnung

ASP.NET MVC von 0 an from .NET Online User Group on Vimeo.

Präsentation

Code (mit Kommentaren)

Feedback & Fragen

Falls du bei dem Vortrag dabei warst und noch Fragen hast oder einen (Verbesserungs)vorschlag oder Feedback hast kannst du das auch gerne als Kommentar posten.

Bis zum nächsten Mal!

12Nov/101

ASP.NET MVC3: Remote Attribut “richtig” nutzen

Seit gestern probiere ich die neuen Attribute in dem ASP.NET MVC3 RC aus und bin eigentlich sehr zufrieden. Nur ein Attribut wollte bisher einfach nicht funktionieren, nämlich das Remote-Attribut.

In den offiziellen Release Notes ist dieses Attribut beschrieben und es wird folgendes Beispiel benutzt um es dem Leser näher zubringen:

image

Dies habe ich auch als Vorlage genommen und meine Methode im Controller implementiert:

image

Doch das hat nicht funktioniert. Nun weiß ich auch wieso, denn hier wird ein falsches Ergebnis zurück gesendet. Das Ergebnis dieser Methode liefert ein “False” oder “True” ab, mit einem großen Buchstaben am Anfang – und das macht uns alles kaputt!

Hier ist unser Request den jQuery für uns erzeugt:

image

Dieser Request kommt erfolgreich auf dem Server an und wird korrekt verarbeitet. Als Response kommt dann folgendes zurück:

image

Man beachte hier das großgeschriebene “False”. Also arbeitet der Controller völlig korrekt, nur müsste er ein kleines “false” zurückgeben.

Nun wenn man es Quick & Dirty haben will kann man einfach einen String zurückgeben:

image

Der bessere Weg wäre wohl ein JSON Result:

image

Nun funktioniert auch alles wie es soll und ich kann ruhig schlafen Smiley

11Nov/101

ASP.NET MVC3: Was gibts neues?

Einige von euch haben es sicher mitbekommen, dass vor Kurzem der Release Candidate (RC) von ASP.NET MVC3 veröffentlich wurde. Download, Changelog. Diese neue Version bringt einige für uns Entwickler tolle neue Funktionen und Vereinfachungen mit.

Die wohl auffälligste Neuerung ist die neue ViewEngine namens Razor, diese sorgt dafür, dass die Views um einiges schlanker und lesbarer werden durch die Einführung einer neuen Syntax.

Ich will mit euch ein kleines Beispielprojekt erstellen in dem wir Schritt für Schritt einige der Neuerungen durchgehen.

Fangen wir an und erstellen ein neues MVC3 Projekt in Visual Studio und bereits hier gibts es was Neues zu betrachten:

Bild 1: Der Neue Projekt erstellen Dialog

Da wir von Vorn beginnen möchten erstellen wir ein neues Leeres Projekt und wählen die neue Razor ViewEngine.

Layout

Wenn man nun einen Blick auf den Projektmappenexplorer wirft, wird man drin nicht viel finden, lediglich eine CSS- und zwei cshtml-Dateien. Die cshtml-Dateien fangen auch noch mit einem Unterstrich (_) an und haben irgendwas mit Layout im Namen.

Was ist das?

Öffnen wir zunächst im Shared-Ordner die Datei _Layout.cshtml.

image

Diese Datei kann man mit einer MasterPage aus MVC2 vergleichen. Wenn ihr genau hinschaut werdet ihr im Title-Tag einen Platzhalter finden und auch im body-div ist einer namens „@RenderBody()“.

Die Layoutseiten in MVC3 funktionieren anders als die in MVC2, auch wenn diese Seite auch Platzhalter besitzt die später mit Inhalt befüllt werden fällt dennoch die Methode RenderBody() auf. Diese Methode ist in jeder Layout-Seite drin und steht immer an der Stelle wo später der Inhalt der Seite  stehen wird. Neben der RenderBody()-Methode gibt es auch die RenderSection()-methode, die auch einen Namen bekommen und auch als optional markiert werden können.

Was auch neu ist, ist dass wir keine <% %> Tags mehr haben in die wir den ASP.NET Code schrieben können, das alles übernimmt nun das @-Zeichen. Das System ist dabei so intelligent, dass es erkennt bis wohin der Code geht weswegen man auch kein schließen Tag benötigt. Weitere Informationen zu der Razor Syntax.

Wie man sieht sind die ganzen JavaScript Verweise auskommentiert. Bitte entfernt die Kommentarmarkierung, da wir diese Skripte bald benötigen.

Gut, schleißen wir diese Datei und werfen nun einen Blick in die „_ViewStat.cshtml“ in unserem Views-Ordner:

image

Der Inhalt hier ist wie man sieht sehr übersichtlich Smiley

Was macht diese Datei nun? Wie man sieht verweist diese auf die _Layout.cshtml die wir eben betrachtet haben, dabei sorgt dieser Verweis dafür, dass alle Views in dem Views-Ordner inkl Unterordner diesen Verweis auch erhalten. Das hat zur Folge, dass man nun nicht mehr in jeder einzelnen View diese Referenz auf die Layoutdatei eintragen muss und spart sich so den redundanten Code.

Viel mehr gibt es dazu eigentlich auch nicht zu sagen. Gehen wir nun zum nächsten Schritt und erstellen eine neue View.

Views

Wenn ihr den View-Hinzufügen Dialog wählt werdet ihr auch hier eine Veränderung feststellen:

image

Wie man sieht kann man nun auch bei jeder einzelnen View wählen, welche ViewEngine man hier gern verwenden möchte. Legen wir eine gewöhnliche View an.

image

Die neue View enthält nun nur diese paar Zeilen Code (siehe Bild oben).

Zuerst wird ein Codeblock aufgemacht mit der @{ … } Syntax, das bedeutet, dass nun nur noch ASP.NET Code kommt bis die schließen Klammer kommt, auch über mehrere Zeilen.

Innerhalb dieses Codeblocks füllen wir nun den Titel unserer Seite, wenn ihr euch erinnern könnt wurde diese Variable in der MasterPage im Title-Tag wieder ausgegeben.

image

Man beachte hier, dass diese Property dynamisch erstellt wird und es die Property „Title“ eigentlich gar nicht gibt. Diese wird dann zur Laufzeit generiert und mit Inhalt befüllt. So kann man beliebig viele solcher Properties anlegen.

In Zeile 3 geben wir an welche MasterPage hier verwendet werden soll, da wir aber bereits die Datei „_ViewStat.cshtml“ in unserem Views-Ordner liegen haben müssen wir innerhalb der View keinen Verweis mehr auf eine Masterpage setzen. (Außer wir wollen eine andere Nutzen) Also können wir diese Zeile aus unserem Code löschen.

Nun fängt schon ab Zeile 6 der normale HTML Quelltext an, ohne dass wir irgendwo einen Zugehörigkeitsbereich definiert haben. Das ist ein weiteres MVC3 / Razor Feature, denn alles wird an der stelle in der MasterPage eingesetzt wo wir die Methode RenderBody() aufrufen. Eine Ausnahme besteht, wenn wir Sektionen in der Masterpage definiert haben, diese würden dann dementsprechend der passenden Sektion zugeordnet werden.

So könnte eine Sektion aussehen:

image

Das wars nun soweit zu dieser View. Wenn ihr mögt könnt ihr nun weiter damit arbeiten wie mit einer gewöhnlichen View.

Nun wollen wir mal ein Formular anlegen, dass wir zum Registrieren eines Benutzers nutzen wollen. Dazu benötigen wir zunächst ein Model auf das wir dann unsere View mit der Form  typisieren.

Legen wir also eine neue Klasse im Models-Verzeichnis an. Die Model Klassen verhalten sich in MVC3 eigentlich genauso wie in MVC2, nun sind aber einige neue Attribute hinzugekommen die ich euch hier mal vorstellen möchte:

image

Wie ihr seht hat meine Modelklasse 5 Eigenschaften. Die ersten drei sind mit dem Attribut [Required] markiert und sind somit Pflichtfelder. Alle Eigenschaften besitzen ein [DisplayName()] Attribut, dass den Text enthält, der später in der View angezeigt werden soll.

Kommen wir nun zu den neuen Attributen. Erstmal das [Required, Compare(…)] Attribut. Dieses Attribut sorgt hier dafür, dass „RepeatEmail“ mit „Email“ verglichen wird und übereinstimmen muss damit die Validierung erfolgreich ist. So müssen wir diese zwei Werte nun nicht mehr im Controller manuell vergleichen.

Weiter unten bei der About-Eigenschaft finden wir ein weiteres neues Attribut namens [SkipRequestValidation] – Im Prinzip sagt der Name schon alles aus. Dieses Attribut sorgt dafür, dass diese Property beim Binding keine Exception wirft wenn dort HTML enthalten ist.

Früher musste man dann im Controller die Action mit einem [ValidateInput(false)] markieren, was natürlich immer noch funktioniert, aber nun kann man auch einzelne Properties bequem markieren ohne gleich für die ganze Methode den Validationinput abzuschalten.

Hier gibts es nun sogar die Möglichkeit bestimmte Properties von der Validierung auszuschließen:

image

Hier werden die Properties “Body” und “Summary” nicht auf HTML Inhalt überprüft.

Wie ihr sehen könnt habe ich ein Attribut auskommentiert. Auf dieses Attribut habe ich mich persönlich sehr gefreut, aber es scheint nicht zu funktionieren (oder ich mache etwas falsch, wenn ihr meinen Fehler seht bitte kommentieren ACHTUNG: dazu habe ich hier ein Update geschrieben)

Dieses RemoteAttribut erlaubt es eine Eigenschaft an eine Methode in einem Controller zu binden und währen der Ausführung der View beim Client im Hintergrund über Ajax aufzurufen. Für den Fall von der Property Name würde die Methode UserNameAvailabla im Controller Register aufgerufen werden, welche ein boolean zurück gibt. So wird dann dynamisch eine Fehlermeldung auf der View erscheinen.

Wenn man dieses RemoteAttribut nun benutzen möchte muss man natürlich die oben angegebene Methode im angegebenen Controller implementieren, zB so:

image

Diese Methode wird dann beim Validieren per Ajax aufgerufen und zeigt dann dementsprechend auch eine Fehlermeldung an (Falls nötig):

image

Zum Schluss möchte ich noch darauf hinweisen, dass ich ein bestimmtes kleines Feature vermisst habe, nämlich eine bequeme Möglichkeit einen String auszugeben ohne diesen mit HTML zu Encoden. Denn soweit bietet Razor leider keine Möglichkeit dafür. Deswegen muss man hier mit einer eigenen kleinen Extension Methode aushelfen.

Das wäre es dann nun auch für heute. Ich habe ein kleines Beispiel Projekt vorbereitet, dass ihr hier herunterladen könnt. (.NET 4.0 VS2010)

21Okt/101

ASP.NET MVC 2: Custom ErrorPages anlegen

Wenn man Webseiten entwickelt möchte man diese natürlich möglichst anschaulich für den Nutzer gestalten, und dazu gehört es auch für den Benutzer anschauliche und auch verständliche Seiten zu präsentieren, auch wenn mal ein Fehler auftaucht. Im Normalfall passen die Default-Fehlerseiten von ASP.NET leider nicht ins Bild der restlichen Seite, weswegen wir gezwungen sind unsere eigenen Fehlerseiten anzulegen.

Bild 1: Typische 404 Fehlermeldung von ASP.NET

Eigene Fehlerseiten sind unter ASP.NET MVC 2 schnell in vier Schritten eingerichtet.

1. Änderungen an der Web.config vornehmen

Zunächst müssen in der Web.config die customErrors eingeschaltet werden. Hier können die Attribute "defaultRedirect", welches die Adresse definiert die im Falle eines Fehlers aufgerufen wird und "mode", dass einstellt ob Fehler angezeigt werden sollen oder nicht.

Mit den inneren "error"-Ästen kann man dazu noch spezifische Seiten zu einzelnen Fehlercodes zuweisen. Man kann hier sowohl eine  absolute Adresse angeben oder nur eine relative. Für alle nicht spezifizierten Errorcodes wird die Url aus dem customError Tag benutzt.

Wenn ihr diese Einstellungen Lokal testen wollt dann solltet ihr auch den "mode" auf "On" stellen, da ihr euere Seiten sonst nicht zu Gesicht bekommt.

2. Anlegen des Controllers für die Fehlerbehandlung

Wie ihr sehen könnt habe ich hier eine lokale Adresse angegeben. Hierbei wird der Controller "Error" aufgerufen und je nach Fehlercode eine andere Methode.

Im Controller haben wir hier eigentlich nichts besonderes:

Ich war an dieser Stelle mal faul und habe nur eine einzige View für alle Fehler angelegt, die dann die übergebene message ausgibt. Dazu kommt noch, dass wir der Response noch den passenden HttpStatusCode übergeben, da manche Anwendungen danach gehen und so prüfen, ob ein Aufruf erfolgreich war.

3. Die View

Wie eben erwähnt macht die View in meinem Beispiel nichts anderes als den Inhalt der Messagevariable auszugeben. Hier könnt ihr natürlich eurer Kreativität freien Lauf lassen und auch für jeden Error eine einzelne View anfertigen.

4. Glogal.asax - Catch All Route registrieren

Zum Schluss sollten wir noch eine sogenannte Catchall Route einrichten, die wir nach allen unseren Routen positionieren damit diese nur greifen kann, wenn keine der anderen gepasst hat, diese Route wird in jedem Fall aufgerufen, wenn keine der vorderen gepasst hat.

Wenn die CatchAll Route greift wird der Home Controller aufgerufen und die Action "NotFound" ausgeführt.

Im Grunde sind wir nun fertig, alle von uns eingetragenen Fehler werden nun abgefangen und durch von uns präparierten Seiten ersetzt. Das einzige was noch passieren kann ist dass ihr im IIS andere ErrorPages eingestellt habt, dann dann werden diese angezeigt und nicht die von euch erstellten. Hier müsst ihr die "Error Responses" auf "Detailed errors" stellen.

Get Adobe Flash playerPlugin by wpburn.com wordpress themes