Hauptsächlich bestand mein heutiger Arbeitstag aus:
Zu Detlefs großer Freude gab’s heute Würstchen zum Frühstück, liebevoll CosmoWienies genannt.
Zusätzlich zur großartigen Tatsache, dass heute Freitag ist und damit das Wochenende vor der Tür steht, beginnt ab morgen mein Winterurlaub im schönen Krimml. In diesem Sinne wünsch ich allen eine schöne Woche 
Seit einiger Zeit haben wir eine Testlizenz einer PMS und damit meine ich nicht etwas das, sondern das hier. Gestern hat uns dann Jörg seine ersten Erfahrungen mit dem System erzählt und uns Teile des Webinterfaces erklärt und wie wir es benutzen sollen. Jetzt hat jeder einen Account und wir verwalten alle projektspezifischen Daten damit: Kontaktadressen, Projektpläne, Tickets, ChangeRequests, etc.
Heute habe ich auch mit Detlef meine bisherigen Änderungen bei Subversion commitet und den Backendjob von gestern fertiggestellt. Da war das kniffligste die HQL-Abfrage. Die sieht jetzt so aus:
select d.id, d.name from Directory d
inner join d.assets a where a.id = :assetID
Die letzte halbe Stunde hab ich mit einem neuen Backendjob begonnen, der zu jedem Asset (nach dessen Directories ich oben gesucht hab’) zusätzlich noch die Namen aller Kontexte liefert, in denen es benutzt wird.
Wie bereits gestern geplant, habe ich das bestehende org.json-Package um zwei Klassen und zwei Interfaces erweitert:
Einerseits den generischen JSONBuilder sowie sein sicherer Bruder SecureJSONBuilder und ein Interface JSONConstructor, um den JSONBuilder und JSONWriter kompatibel zu machen. Dazu musste ich dann org.json.JSONWriter editieren. Das zweite Interface heisst JSONEncoder und fordert die Methode encodeJSON(JSONConstructor json) womit implementierende Klassen, ihre eigene Methodik zur Serialisierung festlegen können. Alle zusätzlichen Klassen liegen jetzt in org.json.extension. Dann nur noch kompilieren, packen und bei Palava als jar einbinden.
Um 15:00 kam heute Frau Prof. Dr. Schiele, um mich einerseits im Praktikum zu besuchen und anderseits, weil sie meine betreunde Dozentin für die Abschlussarbeit ist, auch zwecks Themenfindung. Detlef, Prof. Dr. Schiele und ich saßen etwas über 60 Minuten im Konfi und haben uns recht nett unterhalten. Eigentlich mehr die beiden, aber das war zu verkraften
Bis zur endgültigen Wahl des Themas haben wir/ich bis Ende März Zeit. Cosmocode wird mich gerne dabei unterstützen. Potenzielle Themen wären, wie bereits überlegt, Genetische Algorithmen zum Map-Labeling oder Redesign einzelner Teile des Palava-Frameworks. Konkrete Idee wäre dort etwa die Konzeption und Implementierung eines Asset-Managers für allerlei Multimedia-Content.
Die letzte Stunde war ich dann wieder mit einem Backendjob beschäftigt, hauptsächlich mit dem Schreiben eines HQL-Statements.
Angefangen habe ich heute damit, neben dem Java-Paket von json.org mir Alternativen wie flexjson und SOJO anzusehen. SOJO macht den leichten Eindruck von Overkill, da es neben JSON auch gleich noch XML oder CSV unterstützt, außerdem wirkt es zu komplex und unnötig aufgebläht. Flexjson sieht da schon schlanker aus, allerdings arbeitet es beim serialisieren von Objekten mit Reflektion, um das manuelle Implementieren von Interfaces zu vermeiden. Wir sind also dabei geblieben und werden das org.json-Package um einige Klassen erweitern und entsprechend unseren Bedürfnissen anpassen.
Desweiteren durfte ich heute meinen ersten Palava-Backendjob schreiben, der allerdings noch nicht genutzt wird 
Den Rest des Tages habe ich meinen generischen JSONBuilder bzw. SecureJSONBuilder (incl. Fehlerbehandlung zum debugging) auf Konsistenz mit dem org.json.JSONWriter getrimmt, um nicht später im Betrieb, wenn man zwischen beiden umschaltet, böse Überraschungen zu erleben.
Heute war sozusagen die Vorprobe zur Generalprobe der Uraufführung für meinen JSONObjectBuilder. Dazu musste ich ein bestehendes (aktuelles) Projekt, das Palava verwendet, mit Subversion auschecken und erstmal zum Laufen bringen. Mit Moritz’ Hilfe war das dann relativ schnell gemacht und ich konnte meine Änderungen am Palava-Framework ins bestehende Projekt einbauen. Dann kam die vermutete Überraschung, ich wurde mit Exceptions erschossen 
Das Problem bestand darin, dass mein/unser Konzept darauf basiert, dass sich alle POJOs als JSON Objekte serialisieren, also Key-Value-Pairs eingeschlossen von { und }. Natürlich gibt es aber welche, die sich als JSON Array bauen. also als eine Werteliste beginnend mit [ und am Ende eine ]. Also hab’ ich kurzerhand aus JSONObjectBuilder eine generische JSONBuilder-Klasse programmiert. Die nun, entsprechend ihres Inputs, ein JSONArray bzw. ein JSONObject entwickelt. Getestet, gepackt, eingepielt und ausprobiert. Funktioniert!
Aber… wurde uns (Detlef und mir) gestern eine performantere Lösung vorgeschlagen bzw. aufgezeigt: Bisherige Motivation meiner Arbeit war es, dass JSON-Konstrukte nach der Erstellung noch geändern werden können, sprich bestehende Daten editieren und neue hinzufügen. Nach Detlefs Meinung ist das Editieren zu vernachlässigen, also liegt der Schwerpunkt auf dem Hinzufügen von Daten.
Die Idee ist es nun, den bestehenden JSONWriter von json.org zu verwenden (bzw. soll ich morgen nach Alternativen recherchieren, z.B. flexjson und SOJO) und es nicht den einzelnen Objekten überlassen, sich ihre öffnende und schließende Klammer zusetzen, sondern dem Eltern-Objekt, also dem aufrufenden Kontext. Denn in der höheren Ebene kann generell entschieden werden, ob und wenn welche Daten noch kommen, bevor eine Objektstruktur mit einer } geschlossen wird.
Heute war wieder mal Minimalbesetzung. Detlef hat sich trotz Krankheit ins Büro geschleppt, wahrscheinlich will er alle anstecken, das war nicht so ganz ersichtlich. Wir haben kurz über den JSONObjectBuilder geredet und Performance-Schwachstellen erkannt und Detlef hat mir gezeigt, wie’s schneller geht Morgen werd’ ich dann noch ne Debug-Version der Klasse schreiben, die bei Bedarf Fehleingaben erkennt und entsprechen reagiert. Da diese Fehlerbehandlung aber wieder teuer ist, wird es eben zwei Klassen geben. Eine für den Entwicklungsprozess und eine für den Produktiveinsatz.
Den Rest des Tages hab’ ich mich mit jQuery beschäftig. jQuery ist eine JavaScript Library, die für den Einsatz im Browser gedacht und entwickelt wurde.
Um jQuery zu benutzen musst du es hier runterladen und die folgende Zeile in den head-Tag deines XHTML-Dokumentes übernehmen:
<script src="jquery.js" type="text/javascript"/>
Fertig
Die wohl wichtigste Funktion von jQuery hört auf den Namen $ und wird wie folgt benutzt:
$("#headline")
macht im Grunde dasselbe wie document.getElementById(“headline”), allerdings mit zwei wichtigen Unterschieden.
Will man beispielweise auf alle h3-Elemente innerhalb eines Elements mit der ID “top” einen Clickhandler legen gäbe es drei verschiedene Wege:
<h3 onclick="javascript:clickhandler();">...</h3>
function init() {
var top = document.getElementById("top");
var h3s = top.getElementsByTagName("h3");
for(var i=0; i<h3s.length; i++) {
h3s[i].onclick = clickhandler;
}
}
$("#top h3").click(clickhandler);
Möglichkeit #1 hat denselben Nachteil wie die Nutzung des style-Attributes für CSS-Befehle. Layout und Struktur werden vermengt. Und man muss kein Genie sein, um zu sehen welche der letzten beiden Möglichkeiten die einfachere ist 
Nach drei Tagen recherchieren, testen und rumspielen habe ich gestern mit Detlef über meine Ergebnisse und meine weiteren Aufgaben gesprochen. Um etwas auszuholen:
Palava besteht, wie gesagt, aus einem PHP Frontend und einem Java Backend. Beide kommunizieren über ein selbstgeschriebenes textbasiertes Protokoll. In der aktuellen Version werden vier verschiedene Formate unterstützt: Text, XML, JSON und PHP. Im Moment läuft der Großteil über PHP. Soll heißen: Java erzeugt aus den konkreten Objekten, die übermittelt werden sollen, PHP-konforme Strings, die dann wiederum von PHP mit eval() in PHP-Objekte umgeformt werden. Ähnlich läuft es mit JSON, nur das der eingehende String mit json_decode() in ein Objekt überführt wird. Beide Verfahren sind sehr unflexibel, wenn es darum geht auf Backend-Seite weitere Informationen in ein Objekt zu packen. Java unterstützt nicht, wie etwas ActionScript 3, das Konzept der “Dynamic Objects”, bei denen man zur Laufzeit, ohne Deklaration in der Klasse einem Objekt Attribute und sogar Funktionen zuweisen kann. Optimale Lösung für das Java-Backend wäre also ein Objekt, das alle Informationen meines ursprünglichen Objektes (das es zu senden gilt) in typisierter Form enthält und zusätzlich nach der Instanziierung modifizierbar ist. Hier kommt die json.org-Library ins Spiel. Dort gibt es eine Klasse namens JSONObject, die so etwas wie einen manipulierbaren JSON-String repräsentiert. Intern arbeitet diese Klasse mit einer HashMap<String, Object>, also einer Liste bestehend aus Schlüssel/Werte-Paaren. Diese Map kann beim Initialisieren durch eine andere Map, via Reflexion (getter/public member) oder eben zur Laufzeit mit Daten gefüllt werden. Man hat also ein dynamisch manipulierbares Objekt, das man zu einem Zeitpunkt, vorzugsweise beim Versenden ans Frontend, mit seiner toString()-Methode in einen JSON-String umwandeln kann.
Meine Aufgabe besteht nun darin, eine Klasse zu schreiben (JSONObjectBuilder), mit dessen Hilfe ein Objekt sich selbst möglichst effizient und nachvollziehbar in ein JSON-Objekt überführt. Weil allerdings bisher mit JSON-Strings gearbeitet wurde, kam nur der JSONWriter zum Einsatz. Also muss ein Interface definiert werden, dass dann sowohl der JSONWriter als auch meine JSONObjectBuilder-Klasse implementieren müssen. Und alle Objekte bauen dann auf diese Interface-Methoden auf, ohne wissen zu müssen, ob sie zu einem JSON-String oder zu einem JSONObject werden.
Nachdem ich am Freitag das Projekt mit der automatischen Kartenbeschriftung quasi abgeschlossen habe, bestand meine Aufgabe heute darin, mich in die firmeneigene Java-PHP-Bridge Palava einzuarbeiten. Um genau zu sein, soll ich mich mit JSON beschäftigen und das Framework so hingehend erweitern, dass zum Datenaustausch zwischen Frontend (PHP) und Backend (Java) neben der PHP-Notation nun auch JSON zum Einsatz kommt.
