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 
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 
Heute waren wir das erste Mal zuwenig Leute zum Kickern, und dafür braucht man eigentlich nur vier. Detlef, Marco und Moritz sind immer noch krank. Andi und Tobi waren bei einem Meeting. Oliver hatte frei. Andreas hat diese Woche Berufsschule und Jörg gings dann nachmittags auch noch schlecht, also isser nach Hause gegangen Der harte Kern waren Barbara, Anika, Tilo und ich. Mein Arbeitstag war auch ziemlich unproduktiv. Morgens hab’ ich meine JSONObjectBuilder-Klasse noch etwas überarbeitet und dann Detlef per Mail geschickt. Bis da ein Feedback zurückkommt (wahrscheinlich incl. Verbesserungsvorschlägen) werd’ ich mir mal sIFR genauer angucken und damit rumspielen.
Detlef? Krank.
Moritz? Krank.
Oliver? Krank.
Anika? Krank.
Marco? Krank.
Tobi? Noch (!) gesund.
Andreas?Berufsschule.
Ihr seht, wir sind heute dünn besiedelt. Im Montags-Meeting waren wir heute nur zu fünft (Jörg, Andi, Tobi, Tilo und ich). Die ersten paar Stunden war ich damit beschäftigt, mein bereits funktionierendes Programm zu verstehen (JSONObjectBuilder). War im Grunde nur ein kleiner Denkfehler von mir. Also jetzt kann man mit Hilfe meiner Klasse aus einem POJO (Plain Old Java Object) ein JSONObject bauen. Das klappt auch soweit alles ganz gut, wenn man die korrekte “Syntax” bzw. Reihenfolge der Methodenaufrufe einhält. Da fehlt jetzt noch die Fehlerbehandlung.
Irgendwie hab’ ich’s geschafft, dass meine Klasse (JSONObjectBuilder) genau das macht, was sie soll. Klingt ja erstmal ganz gut. Aber nach meinem Verständnis dürfte es nicht funktionieren. Am Montag werd’ ich also damit beschäftigt sein, herauszufinden, wieso mein Programm das tut was es tut. Ich würd’s “Unconscious Prorgamming” nennen.
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 gestern auf meinen Rechner eine Palava-Umgebung eingerichtet hab’, war ich heute mit JSON beschäftigt. JSON steht für JavaScript Object Notation, ist aber trotz seines Namens unabhängig von der zugrundeliegenden Programmiersprache. Ein String, der in JSON-codiert ist, sieht in etwa so aus:
{
“name” : “alittleobject”,
“next” : null,
“previous” : {“name” : “anotherlittleobject”,
“count” : 18,
“anarray” : [ null, 192, false]}
“number” : 17,
“list” : [ "astring", 127, true ],
“active” : false;
}
JSON ist in gewisser Weise sehr ähnlich zu XML. Aufgrund seiner Nähe zu JavaScript kommt es bevorzugt beim Datenaustausch zwischen Webservern und Browsern, die via Ajax kommunizieren, zum Einsatz.
