ASP.NET MVC I18n – Teil 7: Model Attribute

Home » Dev » ASP.NET MVC I18n – Teil 7: Model Attribute

ASP.NET MVC I18n – Teil 7: Model Attribute

10. Februar 2014

Der letzte Teil hat Ressourcen eingeführt und direkt per Code verwendet. Wenn man View-Anteile lokalisieren will, die auf Daten basieren – als Databinding gegen die Models – kommen ebenfalls Ressourcen ins Spiel.

Hinweis: Dieser Beitrag ist Teil einer Serie, die Übersicht findet sich hier.

Lokalisierung der Daten-bezogenen Informationen ist ein recht gut dokumentierter Aspekt, daher kann ich die Grundlagen im Schnelldurchgang abhandeln und mich auf die Sonderfälle konzentrieren. Wer eine Einführung braucht, findet diese auf der ASP.NET site.

Hinweis: Dieser Beitrag wird sich um Labels und Validierungsfehlermeldungen kümmern; Validierung selbst kommt im nächsten Beitrag.

Das M in MVC steht für das Model, in ASP.NET MVC typischerweise POCOs. Validierung und Lokalisierung basiert auf Attributen auf den Properties der Models. Die erste Frage – die in Tutorials in der Regel nicht gestellt wird – ist eher eine Architekturfrage: Welche Klasse steht für unser Model?

Im initialen Beitrag hatte ich den Business Contract eingeführt, der folgende Datenklasse enthielt:

namespace MyStocks.BusinessContract 
{ 
    [DebuggerDisplay("BusinessContract.Stock: {ID} {Isin} {Name} {Price} {Date}")] 
    public class Stock 
    { 
        public int ID { get; set; } 
        /// <summary> 
        /// http://en.wikipedia.org/wiki/International_Securities_Identification_Number 
        /// 12-character alpha-numerical code 
        /// </summary> 
        public string Isin { get; set; } 
        public string Name { get; set; } 
        public decimal Price { get; set; } 
        public DateTime Date { get; set; } 
    } 
} 

Rein technisch betrachtet könnten wir diese natürlich um die notwendigen Attribute ergänzen, allerdings würde der Contract dann durch UI-Informationen “verunreinigt”. Um es kurz zu machen: Das ist keine gute Idee (das Thema habe ich bereits behandelt).

Stattdessen werden eigene Model-Klassen im Presentation Layer hinterlegt. (Für dieses einfache Beispiel reicht eine Kopie des Data Contracts, nach meiner Erfahrung haben Models aber die Tendenz sich stärker an den Views auszurichten – um den Begriff ViewModel zu vermeiden.)

Darauf kann man dann die Validierungs-Attribute packen:

[DebuggerDisplay("Models.Stock: {ID} {Isin} {Name} {Price} {Date}")]
public class Stock
{
    public int ID { get; set; }
  
    [Required]
    [RegularExpression(@"[a-zA-Z]{2}[w]{9}[d]{1}")]
    public string Isin { get; set; }
  
    [Required]
    public string Name { get; set; }
  
    [Required]
    [DisplayFormat(DataFormatString = "{0:f2}")] // currency would include currency sign
    public decimal Price { get; set; }
  
    [Required]
    [DataType(DataType.Date)]
    public DateTime Date { get; set; }
}

Natürlich wird jetzt ein Datenmapping benötigt. In komplexeren Szenarien würde man hier einen Automatismus, etwa AutoMapper, in Betracht ziehen, in unserem Beispiel ist Handarbeit ausreichend:

using ContractStock = MyStocks.BusinessContract.Stock; // business contract model 
using ModelStock = MyStocks.Mvc.Models.Stock; // mvc model 
  
namespace MyStocks.Mvc.Models 
{ 
    static class Mapper 
    { 
        public static ModelStock MapToUI(this ContractStock stock) 
        { 
            return new ModelStock 
            { 
                Date = stock.Date, 
                ID = stock.ID, 
                Isin = stock.Isin, 
                Name = stock.Name, 
                Price = stock.Price 
            }; 
        } 
         
        public static ContractStock MapToContract(this ModelStock stock) 
        { 
            return new ContractStock { ... }; 
        } 
    } 
} 

Dazu die entsprechenden Aufrufe im Controller:

public class StockController : Controller 
{ 
    protected MyStocks.BusinessContract.IStockService StockService { get; set; } 
     
    public StockController() 
    { 
        this.StockService = new MyStocks.BusinessService.StockService(); 
    } 
     
    // 
    // GET: /Stock/ 
    public ActionResult Index() 
    { 
        var model = StockService.GetAllStocks().Select(Mapper.MapToUI); 
        return View(model); 
    } 

Die größtenteils generierten typisierten Views greifen das Model über Extension-Methods ab:

@model IEnumerable<MyStocks.Mvc.Models.Stock> 
@{ 
     ViewBag.Title = Labels.Navigation_Stock_Index; 
} 
<h2>@ViewBag.Title</h2> 
<table> 
    <tr> 
        <th>@Html.DisplayNameFor(model => model.Isin)</th> 
        <th>@Html.DisplayNameFor(model => model.Name)</th> 
        <th>@Html.DisplayNameFor(model => model.Price)</th> 
        <th>@Html.DisplayNameFor(model => model.Date)</th> 
    </tr> 
    @foreach (var item in Model) 
    { 
        <tr> 
            <td>@Html.ActionLink(item.Isin, "Details", new { id = item.ID })</td> 
            <td>@Html.DisplayFor(modelItem => item.Name)</td> 
            <td style="text-align:right">@Html.DisplayFor(modelItem => item.Price) €</td> 
            <td>@Html.DisplayFor(modelItem => item.Date)</td> 
        </tr> 
    } 
</table> 
<br /> 
<br /> 
@Html.ActionLink(Labels.Navigation_Back, "Index", "Home")

Lässt man die Anwendung laufen ist das Ergebnis folgendermaßen:

Lokalisierung-7-app1

Die Namen der Properties werden als Bezeichner in der Ausgabe verwendet. Springt man in die Details und die Edit-View, werden auch Validierungsfehler gemeldet:

Lokalisierung-7-app2

Es ist sogar möglich, dass die Meldungen bereits übersetzt sind. Das hängt allerdings von der Sprachversion des installierten .NET Framework ab. Generell würde ich mich ohnehin nicht darauf verlassen wollen, dass in Produktion alle benötigten Sprachen vorhanden sind. Spätestens wenn spezifische Meldungen benötigt werden muss man ohnehin Hand anlegen.

Lokalisierte Validierungsmeldungen werden über entsprechende Verweisen auf Ressourcen in den Validierungs-Attributen angegeben. Display kommt für die Labels dazu:

[DebuggerDisplay("Models.Stock: {ID} {Isin} {Name} {Price} {Date}")] 
public class Stock 
{ 
    public int ID { get; set; } 
     
    [Required(ErrorMessageResourceType = typeof(Localizations.Models), ErrorMessageResourceName = "Validation_Required")] 
    [RegularExpression(@"[a-zA-Z]{2}[w]{9}[d]{1}", ErrorMessageResourceType = typeof(Localizations.Models), ErrorMessageResourceName = "Stock_Isin_RegEx")] 
    [Display(ResourceType = typeof(Localizations.Models), Name = "Stock_Isin")] 
    public string Isin { get; set; } 
 
    [...]
} 

Soweit findet man die Informationen durchaus in den üblichen Tutorials. Was hingegen selten erwähnt wird (auch in der Dokumentation nicht) ist die Möglichkeit, string.Format-Platzhalter zu verwenden. Es ist nicht notwendig, für jedes Feld einen eigenen “Feld XY ist ein Pflichtfeld!”-Text zu hinterlegen (wie in manchen Beiträgen dargestellt…).

Alle Validierungs-Attribute unterstützen zumindest Platzhalter für den Feldnamen, bei vielen kommen die eigenen Properties hinzu, etwa die Länge beim MinLengthAttribute. Folgende Texte in den Ressourcen sind also ausreichend für die Standardfälle:

Validation_Required= „{0} is a required field!“

Validation_MaxLength= „{0} must be shorter or equal to {1} characters!“

…

Nebenbei: Wer ein Problem mit der inflationären Verwendung der Attribute hat, findet bei Phil einen Ansatz um die Ressourcen über einen auf Konventionen basierenden Mechanismus automatisch zu verwenden.

Ein Loch müssen wir noch stopfen…

Die meisten Validierungsfehler werden ordentlich lokalisiert, mit einer Ausnahme:

Lokalisierung-7-app3

Die Meldung beim Datum kommt nicht von der Validierung, sondern vom Binding. Binding ist der Mechanismus, der den eingegeben Text in den Datentyp umwandelt (was “syntaktische Korrektheit” impliziert), während die eigentliche Validierung in ASP.NET MVC sich auf inhaltliche (“semantische”) Validierung bezieht. (Hintergründe dazu finden sich hier.)

Für das Binding funktioniert aber auch die Lokalisierung anders. Tatsächlich gibt es nur zwei Fälle, numerische Werte und Datumswerte, und nur einen Weg, die Übersetzungen bereitzustellen:

Man platziert eine Ressource-Datei in App_GlobalResources – Ja, ich sagte der Ordner ist tabu. Das hier ist die Ausnahme die die Regel bestätigt.
Man definiert zwei Meldungen mit exakt diesen Namen:

Dazu kommen natürlich die entsprechend lokalisierten Varianten.

Man teilt dem Model Binder mit, dass er diese Ressource verwenden soll (Name der Ressource, d.h. der Dateiname ohne .resx):

public static void InitializeLocalization() 
{ 
    ClientDataTypeModelValidatorProvider.ResourceClassKey = "GlobalResources"; 
} 

Nebenbei: Falls jemand über DefaultModelBinder.ResourceClassKey stolpert, das ist offensichtlich veraltet…

Und jetzt tut es lückenlos:

Lokalisierung-7-app4

Falls sich jemand fragt, warum dieser Sonderfall so verquer gelöst ist…

“Aside from the standard localization of MVC, this message isn’t easily changeable (it was added at the last minute, and we didn’t offer an override unfortunately).” Im Forum, Kommentar von Brad Wils, Betonung von mir.

LOL!

Der Vollständigkeit halber: Alle diese Aussagen basieren darauf, dass MVC jQuery unobtrusive validation verwendet. Wer jQuery validation direkt verwenden will kann das lokalisieren indem er die Meldungen hinter $.validator.messages übersetzt. Hier gibt es ein Beispiel.