War ja lange ruhig hier, aber jetzt hab’ ich mal wieder Zeit was zu schreiben.
Letzte Woche (10.3.-14.3.) bestand meine Arbeit aus:

• Dummy-CMS für den Usabilitytest aufbauen
  • Bugfixing
  • Change Requests
  • CMS Einweisung für den Kunden (5h Marathon-Meeting!)
• Themenrecherche für meine Bachelorarbeit

Bisherige Ideen waren “Genetischer Maplabeling-Algorithmus” und “Assetmanagement in Palava (palava.cosmocode.de)”. Zum zweiten Thema hat Detlef mir noch was zu lesen gegeben, und zwar eine Java Spezifikation für die “Java Content Repository API” (JSR-170).
Hab’ seit Freitag ungefähr ein Drittel gelesen, außerdem hab ich mit der Referenz-Implementierung Jackrabbit von Apache rumgespielt und gestern dann mal Magnolia installiert. Magnolia ist ein OpenSource-CMS, das auf ein JSR-170-Content-Repository aufbaut, in der aktuellen Version ist das Jackrabbit.

Den Rest der Woche (Mi-Fr) hab’ ich im Prinzip das gleiche gemacht, wie am Dienstag: Ein Dummy-CMS aufgebaut. Wir entwickeln das Web-Frontend für den Relaunch einer Website bestehend aus XHTML, CSS und JavaScript. Für den aktuellen Entwicklungsstand ist ein Usabilitytest vorgesehen, und um die entworfenen Templates mit Leben, sprich Daten, zu füllen, muss ein CMS her. Zu diesem Zweck war ich diese Woche damit beschäftigt (und werde vorraussichtlich auch nächste Woche noch damit beschäftigt sein) ein Dummy-CMS aufzubauen und die Website rudimentär bedienbar/nutzbar zu machen.

Habe mich heute wieder ausgiebig mit formelCMS und unserem aktuellen Frontend-Projekt beschäftigt und bin einen guten Schritt voran gekommen. Die HTML-Komponenten/Snippets werden jetzt korrekt in Templates eingebunden und teilweise bereits mit Daten aus dem Prototyp versorgt. Morgen muss ich dann mit Detlef nochmal die Details durchgehen, weil sich am Layout, im Bezug zum Prototypen, ne Menge geändert hat.

Am Sonnabend bin ich aus dem sonnigen Österreich wieder gekommen. Bei Gelegenheit werd’ ich mal’n paar Fotos hochladen.

Meine Aufgabe an diesem verregneten Montag bestand darin, für ein Projekt, das wir machen, ein Dummy-CMS einzurichten. Kurze Erklärung: Wir bauen das XHTML/CSS/JS/Flash-Frontend und eine andere Firma das dazugehörige CMS. Allerdings brauchen wir für die Entwicklung auch eine Möglichkeit die Seiten bzw. Templates, die von uns erstellt werden, mit Daten zu füllen. Zu diesem Zweck füge ich die erstellten Templates und HTML-Snippets in unser firmeneigenes CMS ein, so das wir die Content-Daten aus unserem Prototyp verwenden können. Die Flat-Version, also pures HTML ohne generierte Inhalte, hab’ ich heute fertig gemacht, morgen werd’ ich dann wahrscheinlich mit Detlefs Hilfe die Seiten mit dynamischen Inhalten versehen.

Hauptsächlich bestand mein heutiger Arbeitstag aus:

• Backendjob(s) schreiben
• JSON/Palava-Framework updaten/testen
• Änderungen bei bestehenden Projekte einspielen, testen und ggf. anpassen

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.

Für alle, die schon immer mal wissen wollten, wieviel HTML (4.0) Tags sie in 5 Minuten benennen können )

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.