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.