Spring MVC, JSP und Datatables „schmutzig“ kombiniert

Die Aufgabe

Unsere Webapplikation basiert auf Spring dem MVC Framework. Die Darstellung der Daten erfolgt unter anderem mittels einer Tabelle. Diese Tabelle soll nun verschiedene Funktionen bereitstellen:

  • Die Tabelle soll sortierbar sein
    • Spalte 4 und 5: Datumsformat: dd.mm.yyy (noch nicht gelöst)
    • Spalte 6: kombinierte Daten mit dem Format: dd.mm.yyy – dd.mm.yyy (noch nicht gelöst)
  • Die Werte sollen im deutschen Zahlenformat (mit Komma) dargestellt werden
  • Der Wert der Ist-Spalte soll editierbar sein
    • Validierung des neuen Wertes
    • Eventuell Änderung der Farbe der Zelle (noch nicht gelöst)

Die noch nicht gelösten Aufgaben werden in Kürze in einem Folgebeitrag behandelt.

 

Die Tabelle sieht wie folgt aus:

tabelle

JSP-Code:

Zur Lösung der genannten Anforderungen wurde sich für die Nutzung von jquery.dataTables entschieden, da diese Skriptsammlung die meisten Forderungen direkt löst oder passende Schnittstellen zur Lösung anbietet.

Problem 1: Sortierung der Tabellen

Eine reine Sortierbarkeit der Tabelle lässt sich schnell erreichen. Die jsp-Datei wird um die Einbindung folgender java-Skript-Datei erweitert:

Zusätzlich bekommt die Tabelle eine id

Und es müssen folgende JavaScript-Zeilen eingebunden werden:

Der Parameter „paging“ : false und „bLengthChange“ : false sind optional.

 

Problem 2: Werte im deutschen Zahlenformat

Die Werte stammen aus dem Object usergroup. Werden die Daten einfach nur in die Tabelle eingefügt besitzen sie die native Darstellung mit „.“ als Dezimaltrenner. Möchte man das in Deutschland übliche „,“ als Trenner reichen folgende Zeilen in der jsp-Datei (z.B. vor der Tabelle)

und um den zu formatierenden Wert

Problem 3: Editierbarkeit von Werten

Eine weitere Anforderung war es, den aktuellen Ist-Zustand zu editieren. Auch hierfür bieten die jquery.dataTables eine Lösung an. Dazu wird der JavaScript-Code am Anfang der jsp-Datei entsprechend erweitert:

sUpdate enthält den Aufruf, der durch den WebService weiter verarbeitet wird. In aoColumns ist der Verarbeitungstyp aller Spalten der Tabelle enthalten. null steht dabei für „keine Editierbarkeit“ und „{}“ für einen Standarteditor. Dieser kann durch weitere Parameter, wie beispielsweise Validierungsparameter ergänzt werden.

Des Weiteren wurden die Tabellenzeilen um ein Attribut „id“ ergänzt, welches automatisch beim Aufruf des Webservices übergeben wird:

Das „Gegenstück“ des Aufrufs befindet sich in der TestController.java. In der Regel wird bei Spring ein Model übergeben, bzw. erzeugt und zurückgegeben. Ein Möglicher Aufruf sieht somit wie folgt aus:

Ziel in unserem Projekt war es, saubere Rest-Anfragen, wie beispielsweise „/edit/{id}“ zu erzeugen. In Kombination mit den jquery.datatables ist dies nicht mehr möglich. Zum einen gibt es, ohne deutliche Eingriffe in den bestehenden Code keine Möglichkeit die notwendigen Parameter, Rest-konform zu übertragen, zum anderen erwartet das Script den Wert von „value“ als Rückgabewert, im Falle einer erfolgreichen Weiterverarbeitung, oder die anzuzeigende Fehlermeldung, falls die Weiterverarbeitung im Controller nicht erfolgreich war. Somit „verschmutzen“ wir jetzt den Spring-MVC Controller.

Damit ergibt sich die Notwendigkeit der Nutzung von:

Beim Aufruf werden verschiedene Elemente, wie z.B. value und id als Parameter übergeben.

 

Validierung des Wertes

Für die Validierung der Werte gibt es zwei Möglichkeiten:

  • Validierung innerhalb der jsp-Datei
  • Validierung im Controller

Fall 1: Validierung innerhalb der jsp-Datei

Wie bereits erwähnt, lässt sich die Editor-Anweisung durch Parameter ergänzen

 

Im aktuellen Fall wurde in einer ersten Variante die Validierung in der jsp-Datei umgesetzt. Dabei weißt „errorTab“ auf die css-Klasse der Fehlermeldung hin:

Diese Validierung bezieht sich auf Fließkommawerte, die „.“ als Trenner verwendet. Zwar wird intern alles korrekt gehandhabt, aber die korrekte Darstellung mit „,“ in der Tabelle erfolgt erst nach einem kompletten Neuladen der Tabelle.

Die Nutzung des deutschen Zahlenformates wurde jedoch zu einem Problem. Zwar gibt es die Möglichkeit numberDE als Validierungsparameter zu setzen, im Ergebnis erlaubte die Validierung aber gar keine Zahlen in der Eingabe. Ein weiterer Wunsch war es, beide Zahlenformate zu erlauben, sowie gleichzeitig eine Begrenzung des Zahlenwertes auf den Bereich 0 bis 100 zu ermöglichen.

Fall 2: Validierung im Controller

Eine einfache naheliegende Lösung, für die ich mich auch entschieden habe, ist die Validierung im Controller vorzunehmen. Im Falle eines Fehlers wird dieser, statt des „value“ zurückgegeben. Im Ergebnis erscheint dann ein Fehler-Fenster mit der Meldung und der Wert wird automatisch auf den Ausgangswert zurückgesetzt. Ein weiterer Vorteil ist, dass man bereits in der Web-Anwendung definierte Validatoren wiederverwenden kann und somit die Anforderungen für die Validierung an einer zentralen Stelle hält.

Für den jsp-Code bedeutet das, dass wieder nur der Standarteditor mittels „{}“ aufgerufen wird. Die Validierung erfolgt im Controller:

 

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.