nicht angemeldet
Hallo Mathias,
ich vermute ja, es geht um ssw, oder?
- JSON wahlweise mit document.write bei der Initialisierung laden, auch wenn's später nicht verwendet wird
- JSON wahlweise asynchron mit createElement bei der Initialisierung laden, auch wenn's später nicht verwendet wird
Ich würde (3) wählen, um auf document.write verzichten zu können, es aber so synchron gestalten, dass ... sagen wir ... implementation.setup() oder eine ähnliche beendende Funktion als load-Handler ausgeführt wird. Ich hätte kein schlechtes Gewissen zu kommunizieren, dass das Skript erst letztendlich erst wirklich in document.onload zur Verfügung steht.
Mich irritiert Dein „auch wenn's später nicht verwendet wird“. Derzeit hast Du doch nur JSON als Serialisierer, alle Deine Möglichkeiten zum Speichern verwenden JSON und ein anderes Text-Format für Datenstrukturen steht nicht auf dem Programm. Hältst Du es wirklich für nötig so extrem flexibel zu sein, nur weil was irgendwann in der Zukunft sein könnte? Mal abgesehen davon, dass Deine Implementierungen mittels des aufsetzenden implementation-Objektes durchaus ihre Bedürfnisse festlegen und damit .detect() bzw. .setup() mitteilen könnten, welche dann darauf eingehen könnten.
OT: Kleines Nitpicking, nimm's mir bitte nicht übel, dass ich das hier anbringe. Ich hätte das Initialisieren des Skriptes durchaus etwas imperativer gestaltet mit einem öffentlichen Wrapper um eine imperativ auszuwählende Storage-Implementierung anstatt eines dafür nötigen größeren Init-Objektes. OOP ist doch letztendlich nur dafür da, gemeinsame Operationen nach außen hin zu kapseln und zu organisieren. Hier hast Du das teilweise schon mit dem anonymen Function-Scope samt eventueller Closure erreichst; weiteres wirkt mehr wie ein OOP-Selbstzweck. Zumindest beim Nachvollziehen des Codes ist das hier eher hinderlich, dafür gibt es zuviele Stellen, an denen der Programmfluss innerhalb der Initialisierung springt. Oder übersehe ich was wirklich entscheidendes, was Du schon erkannt hast?
Tim
JürgenB