- modulare Seiten mit Spring MVC und DWR baut
- mit DWR von einander abhängige GUI- Komponenten updated
- locale spezfische Messages im JavaScript anzeigt.
Wo wird valdiert? Beim Client, beim Server, bei beiden?
Klar ist, dass eine Hybrid-Lösung bei der Validierung nicht anzustreben ist, da man die Valdierungslogik auf Client und Server verteilt - nicht wartbar.
Auf dem Client mittels JavaScript valdieren hat viele Vorteile, aber auch Nachteile, wobei reine serverseitig Valdierung technisch zwar optimal, sich jedoch schlecht auf die user experience auswirkt.
Optimal wäre es, wenn man die Valdierung serverseitig erledigen könnte, diese allerdings mittels AJAX asynchron durchführen würde, um dem Benutzer lästige POSTBACK Szenarien zu ersparen.
Für Spring MVC gibt es hierfür eine sauber Lösung, basierend auf dem Validator Muster von Spring - der Artikel von Eric Spiegelberg "Ajax Form Validation Using Spring and DWR" erklärt, wie.
Ich möchte der Lösung allerdings eine Schwachstelle zugestehen - Locale Resolving! Der Ansatz von Eric Spiegelberg setzt voraus, dass bei der serverseitigen Validierung die Locale über den ThreadLocal geführt und mit LocaleContextHolder.getLocale() abgerufen wird, was in einem reinen Spring Container möglich ist.
Oft ist es allderings so, dass das Locale Resolving für Valdierungsfehler nicht am ThreadLocal aufgelöst werden kann, sondern nur im Client - der Server kennt die Locale des Clients nicht, beispielsweise bei folgendem DWR call:
./dwr/call/plaincall/cartManager.getCart.dwrEin mögliche Lösung wäre, das Locale Resovling nicht auf dem Server durchzuführen, sondern so wie meinen vorherigen Artikel per JavaScript.
Eine andere, vielleicht technisch optimaler Lösung wäre, das man beim DWR call die Language übermittelt um diese an den ThreadLocal zu heften.
Keine Kommentare:
Kommentar veröffentlichen