Analog zum Beispiel mit dem Login-Check sollte man auch bei allen anderen Fehlern, die bei Ajax-Aufrufen passieren, den Benutzer nicht im Regen stehen lassen. Im klassischen Fall eines GET- oder POST-Aufrufs erhält man ja schließlich auch eine Fehlermeldung (mal mehr und mal weniger schön und vielsagend), das sollte auch für Ajax-Aufrufe gelten, bei denen Fehler ansonsten "verschluckt" werden.
Das Konzept der FormsAuthentication, welches bereits mit ASP.NET 1.0 anno 2002 eingeführt wurde, hat auch in ASP.NET MVC Bestand (auch wenn man auf Membership-, Profile-Provider und das andere Gedöns heute getrost verzichten kann/sollte). Es wurde ganz elegant übernommen, in dem man die Authentifizierungs-Prüfung über Attribute jeweils auf Action- oder Controller-Ebene regeln kann.
Ein immer wiederkehrendes Szenario bei Webapplikationen ist naturgemäß das Posten von Text(-Nachrichten) über Formulare und das Ausgeben dieser Texte, sei es in Foren, auf Profilseiten oder was auch immer. Da der Mensch bequem ist, setzt man ihm für seine Formatierungen einen WYSIWYG-Editor vor die Nase (z.B. CKEditor, sehr zu empfehlen), über den er ganz bequem seine Formatierungen für seinen Text vornehmen kann.
Ich muss zugeben: das hat mich ganz schön fuchsig gemacht. ASP.NET MVC 3 RC2 war installiert, alle Web.config-Einträge von Hand nach Vorlage eines Demoprojektes aktualisiert und die gut 90 Views im Projekt von Hand von .aspx/.ascx auf .cshtml und damit von der WebForms- zur Razor-ViewEngine umgestellt.
Wenn man mit der WebForms-ViewEngine arbeitet, ist die Sache relativ klar: ganze Seiten bekommen eine .aspx-View, Teile, also so genannte "Partials", bekommen eine .ascx-View. Der Unterschied, der auch historisch bedingt aus der WebForms-Ecke kommt: einem .ascx kann man keine Masterpage zuweisen, es enthält immer nur Teile einer fertigen HTML-Datei. Damit war die Sache hier erledigt.
Kleiner Schock nach der Umstellung vorhandenen Codes von MVC 1 oder 2 auf MVC 3: der in eigenen Extension-Methods generierte HTML-Code wird plötzlich in der Website lesbar dargestellt. Was passiert da?
Ich habe es mir angewöhnt bestimmte in den Views immer wiederkehrende Sachen in entsprechende Basisklassen zu packen, über die ich dann einen einfache und typisierten Zugriff darauf bekomme - als Beispiel wäre der angemeldete Benutzer zu nennen.
Wie ja vor knapp zwei Wochen bereits geschrieben ist die Entscheidung für ein neues Hardware-Setup bei mir gegen ein einzelnes Notebook zu Gunsten der Kombination aus einem Windows-Desktop und einem MacBook Air gefallen. Während der Desktop noch auf die SSD aus dem alten MacBook wartet, die ich wegen einer völlig kaputter Schraube von Profis befreien lassen muss, habe ich das MacBook Air inzwischen eingerichtet und auch den ersten Alltags-Tests unterziehen können. Nachfolgend dazu mein erstes kurzes Fazit.
Da mein MacBook 13" (Late 2008) langsam etwas zu schwach wird, musste Ersatz für mein Homeoffice und unterwegs her. Meine Anforderungen an ein neues Notebook ...
Ich habe im aktuellen Projekt häufiger den Fall, dass ich eine Controller-Action auf zwei Wegen anspreche: einmal über einen Ajax-Request, abgesetzt mit jQuery, und einmal über einen ganz normalen Formular-Roundtrip zum Server. Vor allem bei Letzterem gehört es dazu, diese Requests mit einem so genannten "anti-forgery token" gegen Cross-Site-Attacken abzusichern.
