In meinem Fall habe ich mich für das Grails-UI Plugin entschieden. Dieses Plugin bietet eine schöne Integration von YUI und YUI wiederum bietet ein umfangreiches Set an Rich UI Komponenten.

Das Plugin war schnell installiert und die Integration in Grails war auch relativ leicht umzusetzen. Vor allem das Tag <gui:dataTable> kam bei mir stark zum Einsatz. Irgendwann allerdings kam ich zu dem Punkt, wo ich mich mit Internationalisierung auseinandersetzen musste und dieses Problem war leider nur sehr dürftig beschrieben. Aus diesem Grund will ich heute kurz aufzeigen was man hierfür alles tun muss.

i18n für YUI

Um YUI zu internationalisieren muss man ein wenig in der offiziellen Doku suchen. Leider habe ich kein durchgängiges Konzept erkennen können. Teilweise müssen einfach statische JS Variablen umdefiniert werden, teilweise muss eine Variable im prototype überschrieben werden und teilweise müssen sog. Data Formatter definiert werden, die z.B. eine Datumszelle entsprechend formatieren.

  YAHOO.widget.Calendar.DEFAULT_CONFIG.NAV.value = true;
  YAHOO.widget.Calendar.DEFAULT_CONFIG.CLOSE.value = "Schlie\u00DFen"

  // Correct formats for Germany: dd.mm.yyyy, dd.mm, mm.yyyy
  YAHOO.widget.Calendar.DEFAULT_CONFIG.DATE_FIELD_DELIMITER.value = ".";

  YAHOO.widget.Calendar.DEFAULT_CONFIG.MDY_DAY_POSITION.value = 1;
  YAHOO.widget.Calendar.DEFAULT_CONFIG.MDY_MONTH_POSITION.value = 2;
  YAHOO.widget.Calendar.DEFAULT_CONFIG.MDY_YEAR_POSITION.value = 3;

  YAHOO.widget.Calendar.DEFAULT_CONFIG.MD_DAY_POSITION.value = 1;
  YAHOO.widget.Calendar.DEFAULT_CONFIG.MD_MONTH_POSITION.value = 2;

  // Date labels for German locale
  YAHOO.widget.Calendar.DEFAULT_CONFIG.MONTHS_SHORT.value = ["Jan", "Feb", "M\u00E4r", "Apr", "Mai", "Jun", "Jul", "Aug", "Sep", "Okt", "Nov", "Dez"];
  YAHOO.widget.Calendar.DEFAULT_CONFIG.MONTHS_LONG.value = ["Januar", "Februar", "M\u00E4rz", "April", "Mai", "Juni", "Juli", "August", "September", "Oktober", "November", "Dezember"];
  YAHOO.widget.Calendar.DEFAULT_CONFIG.WEEKDAYS_1CHAR.value = ["S", "M", "D", "M", "D", "F", "S"];
  YAHOO.widget.Calendar.DEFAULT_CONFIG.WEEKDAYS_SHORT.value = ["So", "Mo", "Di", "Mi", "Do", "Fr", "Sa"];
  YAHOO.widget.Calendar.DEFAULT_CONFIG.WEEKDAYS_MEDIUM.value = ["Son", "Mon", "Die", "Mit", "Don", "Fre", "Sam"];
  YAHOO.widget.Calendar.DEFAULT_CONFIG.WEEKDAYS_LONG.value = ["Sonntag", "Montag", "Dienstag", "Mittwoch", "Donnerstag", "Freitag", "Samstag"];

  // Start the week on a Monday (Sunday == 0)
  YAHOO.widget.Calendar.DEFAULT_CONFIG.START_WEEKDAY.value = 1;

  //CalendarNavigator show up if clicked on the current month
  YAHOO.widget.CalendarNavigator.DEFAULT_CONFIG.strings.submit = "OK"
  YAHOO.widget.CalendarNavigator.DEFAULT_CONFIG.strings.cancel = "Abbr."
  YAHOO.widget.CalendarNavigator.DEFAULT_CONFIG.strings.invalidYear = "Das Jahr muss eine Zahl sein."
  YAHOO.widget.CalendarNavigator.DEFAULT_CONFIG.strings.month = "Monat"
  YAHOO.widget.CalendarNavigator.DEFAULT_CONFIG.strings.year = "Jahr"

    YAHOO.widget.BaseCellEditor.prototype.LABEL_SAVE = "OK"
    YAHOO.widget.BaseCellEditor.prototype.LABEL_CANCEL = "Abbr."

    /*
     * BUGFIX for YUI < 2.9
     * If a date cell contains a null value the cell editor calendar does not show up.
     * Till we're not using YUI 2.9 and above this is the fix for it.
     *
     * http://yuilibrary.com/projects/yui2/ticket/2529117
     */
    YAHOO.widget.DateCellEditor.prototype.resetForm = function() {
      var value = this.value || new Date();
      var selectedValue = (value.getMonth()+1)+"/"+value.getDate()+"/"+value.getFullYear();
      this.calendar.cfg.setProperty("selected",selectedValue,false);
      this.calendar.render();
    };

    YAHOO.widget.DataTable.Formatter.date = function(elCell, oRecord, oColumn, oData) {
      var oDate = oData;
      if(oDate instanceof Date) {
        elCell.innerHTML = YAHOO.util.Date.format(oDate, { format: "%d.%m.%Y"});
      } else {
        elCell.innerHTML = '';
      }
    };

Damit hat man zumindest den reinen YUI DataTable umgestellt. Der große Teil ist hier einfach die Übersetzung der englischen Strings in die jeweilige Zielsprache. Ein kleinerer Teil ist die Verwendung eines speziellen DateFormatters, damit in der Zelle selbst ein deutsches Format verwendet wird, und zum Schluss noch ein Bugfix für YUI selbst, denn das Grails Plugin verwendet momentan noch YUI in der Version 2.8. In dieser Version ist es unmöglich für eine leere Datums Tabellenzelle einen neuen Wert zu definieren. Sollte das Grails Plugin irgendwann YUI die Version 2.9 verwenden entfällt dieser Bugfix.

i18n für Grails

Hat man YUI nun eine andere Sprache beigebracht, muss man sich jetzt noch um den Grails Teil kümmern. Folgender Template Code demonstriert dies kurz.

        <!-- http://jira.grails.org/browse/GPUI-250 -->
        <g:set var="i18nfirstName" value="${message(code: 'user.firstName.label', default: 'First Name')}"/>
        <g:set var="i18nlastName" value="${message(code: 'user.lastName.label', default: 'Last Name')}" />
        <g:set var="i18ndate" value="${message(code: 'user.date.label', default: 'Date')}" />

        <g:set var="i18nfirstPage" value="${message(code: 'disy.paginator.firstPage.label', default: 'First Page')}" />
        <g:set var="i18npreviousPage" value="${message(code: 'disy.paginator.previousPage.label', default: 'Previous Page')}" />
        <g:set var="i18nnextPage" value="${message(code: 'disy.paginator.nextPage.label', default: 'Next Page')}" />
        <g:set var="i18nlastPage" value="${message(code: 'disy.paginator.lastPage.label', default: 'Last Page')}" />

        <gui:dataTable
          id="myList"
          selectionMode="standard"
          draggableColumns="true"
          sortedBy="lastName"
          columnDefs="[
                  [id:'Id',
                   hidden: true ],

                  [lastName: i18nlastName,
                   formatter:  'text' ,
                   editor:[controller:'myController', action:'tableChange', onSuccess:'successCallback', onFailure:'failureCallback'],
                   sortable:true,
                   resizeable: true],

                  [firstName: i18nfirstName,
                   formatter:  'text' ,
                   editor:[controller:'myController', action:'tableChange', onSuccess:'successCallback', onFailure:'failureCallback'],
                   sortable:true,
                   resizeable: true],

                  [date: i18ndate,
                   formatter:  'date',
                   editor:[controller:'myController', action:'tableChange', onSuccess:'successCallback', onFailure:'failureCallback'],
                   sortable:true,
                   resizeable: true]]"
          allowExclusiveSort='true'
          controller="myController" action="listJSON"
          rowsPerPage="30"
          MSG_EMPTY="${message(code: 'dataTable.empty.label', default: 'No records found.')}"
          MSG_ERROR="${message(code: 'dataTable.error.label', default: 'Data error.')}"
          MSG_LOADING="${message(code: 'dataTable.loading.label', default: 'Loading...')}"
          paginatorConfig="[
            firstPageLinkLabel: '&lt;&lt;',
            firstPageLinkTitle: i18nfirstPage,
            previousPageLinkLabel: '&lt;',
            previousPageLinkTitle: i18npreviousPage,
            nextPageLinkLabel: '&gt;',
            nextPageLinkTitle: i18nnextPage,
            lastPageLinkLabel: '&gt;&gt;',
            lastPageLinkTitle: i18nlastPage
          ]" />

HIerbei fällt folgendes auf:

• Der Pager wird als paginatorConfig umdefiniert, damit dieser auch in der gewünschten Zielsprache ist.
• Die Default Texte für einen leeren DataTable (MSG_EMPTY, MSG_ERROR, MSG_LOADING) werden ebenfalls definiert.
• Alle Zellenüberschriften werden zuvor als Grails Variable angelegt und verwendet. Dies ist leider noch ein Feature Request für gui:dataTable und vielleicht wird dies in absehbarer Zeit umgesetzt.

Damit hat man nun einen DataTable, der fast fertig ist. Fast deswegen, weil die übermittelten Werte des YUI DataTable auf Controller Seite noch formatiert werden müssen. Werden neue Datumswerte ausgewählt, dann überträgt YUI dies in einem bestimmten DateFormat, welches wir auf Grails Seite bei einem AJAX Update entsprechend in unser Date parsen müssen.

    //Parse param
    if (params.field == 'date') {
      SimpleDateFormat formatter = new java.text.SimpleDateFormat("E MMM dd yyyy HH:mm:ss ZZZZZZZ", Locale.ROOT);
      myObject."$params.field" = formatter.fomrmat(params.newValue)
    }

Haben wir all diese Schritte entsprechend umgesetzt, sollten wir nun in der Lage sein einen internationalisierten gui:dataTable zu verwenden.

Solche Anwendungen setzen immer mehr moderne Browser voraus und das alles wäre ohne den intensiven Einsatz von JavaScript gar nicht erst möglich.

Das JavaScript immer leistungsfähiger wird demonstriert nun das Projekt von Fabrice Bellard. Seit der Einführung von Typed Arrays in JavaScript wird einem nicht nur typsichere Programmierung erleichtert, sondern sie ermöglicht auch die Emulation eines Prozessors. Dies wird eindrucksvoll mit dem Projekt JSLinux demonstriert. Bellard stellt eine x86-kompatible 32-Bit-CPU, einen Interrupt Controller, Interrupt Timer und eine serielle Schnittstelle in gut 90 KByte bereit. Das wiederum dient als Basis um, zugegeben auf Basis eines etwas veralteten Linux Kernel, ein komplettes Betriebssystem im Browser laufen zu lassen. Allen JavaScript Skeptikern oder Linux Neulingen empfehle ich hiermit dieses OS einmal dringend auszuprobieren.

Eine Anmerkung noch zum Schluss. JSLinux hat dann doch eine kleine Voraussetzung. Der Einsatz von TypedArrays setzt leider einen aktuellen Browser voraus. Momentan läuft JSLinux nur unter Firefox 4 und Chrome 11. Solltet ihr dem nicht entsprechen könnt ihr euren Ausflug auch gleich mit der Installation eines modernen Browsers verbinden.

Ganz anders sieht es allerdings aus wenn man das gleiche in JavaScript machen will. JAXB gibt es für JavaScript leider nicht und das parsen von XML in JavaScript ist leider auch nicht wirklich komfortabel. Auch wenn JSON mehr und mehr auf dem Vormarsch ist, kommt man teilweise doch nicht drum herum XML zu verarbeiten. Wie schön wäre es da, wenn man die gleichen komfortablen Mechanismen wie in Java hätte.

Nun, die gibt es. Auf meine Streifzügen durchs Web bin ich heute auf das Projekt Jsonix gestoßen. Dieses Projekt orientiert sich eindeutig am JAXB Paradigma. Es bietet einem die gleichen komfortablen Mechanismen und es nimmt einem die lästige Arbeit ab XML in JavaScript Objekte zu wandeln.

Kleiner Vorgeschmack gefällig?

Mal angenommen wir wollen folgendes XML File in JavaScript einlesen und in JSON verwandeln.

  
    Alice Smith
    123 Maple Street
    Mill Valley
    CA
    90952
  
  
    Robert Smith
    8 Oak Avenue
    Old Town
    PA
    95819
  
  Hurry, my lawn is going wild!
  
    
Lawnmower
      1
      148.95
      Confirm this is electric
    
    
Baby Monitor
      1
      39.98
      1999-05-21
    
  

Um dieses XML File einzulesen müssen wir in Jsonix folgende Zeilen Code schreiben.

var PO = { };
var context = new Jsonix.Context([ PO ]);
var unmarshaller = context.createUnmarshaller();
unmarshaller.unmarshalURL('/org/hisrc/jsonix/samples/po/test/po-0.xml',
  function(result) {
    assertEquals('Alice Smith', result.value.shipTo.name);
    assertEquals('Baby Monitor', result.value.item[1].productName);
  }
);

Sieht gut aus? Stimmt! Der geneigte JAXB User erkennt deutlich die Parallelen. Meiner Meinung nach ist dies eine deutliche Erleichterung um XML mit JavaScript einzulesen. Jsonix hat auf jeden Fall meine Aufmerksamkeit verdient.

Nichts leichter als das. Firebug anwerfen und HTML Code lesen. Jedoch stößt man schnell an seine Grenzen, denn es gibt heutzutage nur noch sehr wenige Webseiten, die ohne JavaScript Code auskommen. Auch kein Problem, denkt sich der geneigte Webentwickler und wirft schnell einen Blick auf den Script Tab von Firebug. Nur dumm, daß der ausgelieferte JavaScript Code komprimiert ausgeliefert wird und damit meine ich jetzt nicht gzip, sondern tatsächlich komprimiert. Warum? Nun, viele Seiten und Frameworks verwenden meist ein Build Tool, welches einmalig alle einzelnen JavaScript Dateien in eine Datei packt. So wird aus tausend kleinen JS Dateien eine große. Doch damit nicht genug, denn meistens werden anschließend auch noch alle Formatierungen über Board geworfen. Eine große JS Datei kann man zumindest teilweise verstehen, doch ohne Codeformatierung geht meistens nichts mehr. Mal eben einen Breakpoint in Firebug setzen und durch fremden JS Code durchdebuggen wenn der gesamte Code in einer einzigen Zeile steht? Keine Chance!

Doch das muss nicht sein. Heute bin ich über ein kleines Firefox Add-On gestoßen, welches diesem Umstand endlich ein Ende setzt. Es nennt sich JavaScript Deminifier. Einmal installiert muss man es lediglich nur noch auf der gewünschten Seite aktivieren und endlich kann man den JS Code lesen, verstehen und nachvollziehen. Schön das die meisten Webseiten nur diese Art der Code Obfuscation nutzen. Endlich kann man sich wieder die ein oder andere Idee holen.

In diesem Sinne viel Spaß beim Fremd-Code studieren ;)

[code lang='xhtml'] value="#{richNavigatorBean.treeNode}" var="node">[/code]

Doch zurück zum eigentlichen Problem. Ein genauerer Blick in den von Tomahawk generierten Quellcode brachte mich auf eine Idee.
[code lang='xhtml']
[/code]
Wie man unschwer erkennt rendert Tomahawk in alle Images zum auf- und zuklappen ein onclick event, welches die treeNavClick Funktion triggert. Die Idee besteht nun darin, daß bei einem onclick auf den Ordner oder dessen Beschriftung eben jene treeNavClick Funktion getriggert wird. Dies ist, wenn man sich in Prototype ein wenig auskennt, kein Problem.

Zuerst passen wir das Rendering der t:tree2 Koponente ein wenig an.
[code lang='xhtml']
binding="#{navigatorBean.newTree}" var="node">



value="#{contextPath}/#{themePath}/images/tree/folder_open_new.gif"
rendered="#{toggler.nodeExpanded}" styleClass="folderIcon" onclick="treeNavigatorExpand($(this));" />


value="#{contextPath}/#{themePath}/images/tree/folder_close_new.gif"
rendered="#{!toggler.nodeExpanded}" styleClass="folderIcon" onclick="treeNavigatorExpand($(this));" />




...
[/code]
Rendert Tomahawk jetzt die Koponente erneut haben wir nun für alle Folder und dessen Beschriftung onclick events definiert. Diese events triggern die JS Funktion treeNavigatorExpand(this), welche folgendermaßen aufgebaut ist:
[code lang='javascript']
function treeNavigatorExpand(element){
element.up(1).select('img[onclick]')[0].onclick();
}
[/code]

Und fertig ist der Hack.

Nun wie funktioniert dieser? Ganz einfach. Bei einem onclick event auf den Folder oder dessen Beschriftung springen wir im DOM zwei parents nach oben, was bedeutet das wir uns in der aktuellen Tabellenzeile befinden (tr). Nun suchen wir ab dieser Zeile alle Images, die ein onclick event haben und verwenden dort das erste Element. Dieses Element ist eben besagtes auf- und zuklapp Icon von Tomahawk und dieses definiert die gewünschte treeNavClick Funktion, welche wir nur noch aufrufen müssen.

Zugegeben, das ist nicht die eleganteste Lösung, aber wie schon oben erwähnt, es ist ein Hack und ein Hack muss nicht immer elegant sein ;-)

Doch was ist, wenn man nun ein allgemeine Funktion schreiben will, in der der Name des Frames dynamisch übergeben wird? In diesem Fall kann man die einfache Notation von oben nicht verwenden.

Ein kurzer Blick in meine JavaScript Bibel, JavaScript the Definitive Guide, brachte dann die Erkenntnis. Zuerst einmal geht man einfach davon aus, dass man zur Laufzeit sich in einem Frame befindet. Sollte der Frame gewechselt werden, greift man zunächst auf parent, also das FrameSet zu. Von dort aus können wir mit der $(domElement) Funktion auf das gewollte Frame zugreifen, voraussgesetzt es verwendet eine id.

[code lang='xhtml']






<br /> <body></p> <div> Das HTML-Frameset kann von Ihrem Browser leider nicht angezeigt werden. </div> <p> </body><br />

[/code]

Nehmen wir also an, daß unsere JS Code gerade in leftFrame ausgeführt wird und das wir in mainFrame auf ein DOM Element zugreifen wollen. Wir müssen also von leftFrame auf parent, dann auch mainFrame, dann auf dessen DOM und dort das DOMElement suchen. Hier nun der korrekte JS Code

[code lang='javascript']
parent.$(mainFrame).contentDocument.defaultView.$(domElement)
[/code]

Folgendes war meine Ausgangssituation:
[code lang='xhtml']

[/code]
In dieses div Snippet wollte ich nun ein weiteres DIV Element mit der id contentIntroduction einfügen. Dabei sollte dieses div genau zwischen die zwei bestehenden divs navigation und content eingefügt werden. Ein kurzer Blick in die Prototype API führte dann auch gleich die Element.insert Methode zu Tage. Leider ist die Dokumentation an dieser Stelle ein wenig dürftig, weshalb ich zunächst auch etwas rumprobieren musste, bis ich es wirklich verstanden habe.

Für mein beschriebenes Problem müsste die Prototype Variante also folgendermaßen aussehen.
[code lang='xhtml']
var contentIntroductionElement = new Element('div', {
'id' : 'contentIntroduction',
'class': 'intro',
}).update('This is a simple and short content introduction');

var contentElement = $('navigation');

Element.insert(contentElement, {'after': contentIntroductionElement});
[/code]

Zu lesen ist das Ganze folgendermaßen. Klasse Element, hole Dir das DOM-Element navigation und füge danach das DOM-Element contentIntroductionElement ein. Es muss natürlich nicht nur before sein. Prototype lässt auch before, top und bottom zu.

Das Ergebnis sind dann folgendermaßen aus:
[code lang='xhtml']

[/code]

Kein Problem denkt sich der Programmierer und erweitert die  Backendmethoden seiner DAO’s um eine Sortiermöglichkeit. Das Ganze wird dann aber etwas schwieriger oder ressourcenfressender wenn man eine Sortierung von komplexen JOIN Statements  sortierbar machen will. Im schlimmsten Falle wählt der User nämlich immer genau die Sortierung aus, die aus DB Sicht gar nicht schlau oder ideal ist. Eine Sortierung einer Spalte, wo kein Index oder Primary Key vorhanden ist kann so schnell zu Höllenqual werden und nicht selten leidet dann die Komplexität des Backendcodes darunter.

Wie wäre es also mit einer Lösung für den Client? Wenn der User schon mitunter komische Sorierungsmöglichkeiten haben will, warum sollte dann dies nicht der Client selbst machen? Vorteil wäre, daß der Server nicht unnötig durch andauernde Sortierrequest lahm gelegt wird und der User hat obendrein noch das Gefühl, daß die Sortierung sehr schnell geht.

Eben dieser Usecase lässt sich ganz leicht mit der JS Bibliothek Tablekit realisieren. Der Programmierer muss noch nicht einmal besonders begabt sein, denn alles was benötigt wird ist eine zusätzliche CSS Klassenangabe im table tag. Klingt einfach, oder?

Ist es auch. Um Tablekit zu verwenden benötigt man nur Prototype als Basisbibliothek und eben Tablekit. Danach muss man nur noch alle table tags mit der von Tablekit vorgegebenen Klassebezeichnung sortable auszeichnen und schon erstrahlt die Tabelle in neuer Funktionsvielfalt. Über JS ermittelt Tablekit zunächst den verwendeten Datentyp, denn ein Datum wird immer noch anders sortiert als ein String. Ist der Datentyp bestimmt, sortiert Tablekit entsprechend. Programmieraufwand gleich null. Den Programmierer, den Server, die DB und den Endanwender wird es freuen.

Ein paar Einschränkungen gibt es dann aber doch. Tablekit sortiert immer nur die Datenmenge, die auch zum Zeitpunkt des Renderings vorhanden ist. Sollte eure Tabelle also einen Paging Mechanismus verwenden, dann wird Tablekit auch nur diese entsprechend sortieren, d.h. wenn ihr z.b. die zweite Seite einer Tabelle sortiert, dann wird auch leider nur diese Seite sortiert und nicht die gesamte Datenmenge. Wie denn auch? Trotzdem ist Tablekit hier eine schnelle und hervorangende Wahl, um mit möglichst geringen Aufwand schnelle Ergebnise zu erzielen.