nicht angemeldet
Hakuna matata!
Nachteil der AJAX-Lösung ist allerdings (um das auch mal zu beleuchten), dass ich damit noch mehr Requests aka Traffic aka Ladezeit benötige.
Das ist sehr kurzsichtig. Initial findet ein Request mehr statt, das bedeutet zusätzlicher Overhead, ABER: Bei der Ajax-Lösung hat man eine saubere Trennung zwischen Programmlogik (JavaScript) und dynmaischen Zuständen (JSON). Die Programmlogik wird sich hoffentlich nicht all zu oft ändern, die Zustände vermutlich schon. Bei der Ajax-Lösung ist es deshalb möglich die Programm-Logik sehr lange zu cachen und nur die Zustände regelmäßig neu anzufordern. Bei eurer Lösung, wird beides über einen Kamm gescherrt und infolgedessen muss das gesamte JavaScript-Teilprogramm neugeladen werden, wenn sich nur die Zustände ändern.
Plus: ich kann die Werte noch nicht von Anfang an nutzen (da ich ja erst den asynchron ausgeführten request abwarten muss).
Ich bezweifle, dass das zu einem Falschenhals werden könnte. Und auf der anderen Seite, erlaubt die AJAX-Variante natürlich auch zwischendurch kleine Anfragen abzuschicken, s.o.
Außerdem ist aufgrund der zentralen Einbindung der Werte die Manipulierbarkeit genauso groß und einfach, wie bei meinem ursprünglichen Beispiel.
Was wunderbar ist, denn dein ursprüngliches Beispiel hat kein Problem mit Manipulierbarkeit ;)
Und ich habe wieder redundanten Code, weil ich den AJAX für jedes einzubindende Javascript einzeln ausführen muss, da diese ja optimalerweise auch unabhängig voneinander stattfinden sollen.
Ich sehe nicht, wieso das zu redundatem Code führen sollte? Kannst du ein Mini-Beispiel bauen? Ich bin mir sicher, dass sich auch dafür schnell eine Lösung finden ließe. In der Regel, kann man das DRY-Prinzip immer sehr einfach erreichen, indem man ein zustätzlichen Level an Abstraktion einfügt, häufig kann das bereits durch eine einfache Funktion erreicht werden.
Wobei, einen Vorteil, den die anderen Methoden nicht haben, sehe ich noch. Man kann damit erhöhte Manipulationssicherheit […]
Es gibt hier kein Sicherheitsproblem mit Manipulation, der Nutzer kann natürlich mit seinen Entwicklertools auch das <html>-Element löschen und kriegt so gar nichts mehr zu sehen, aber das ist ein Fall gegen den wir unsere Anwendung nicht absichern müssen. Wichtig ist, dass der Nutzer nicht in der Lage ist, irgendwelche Prozesse auf dem Server zu starten, zu denen er nicht berechtigt ist, und da öffnet keiner der vorgeschlagenen Lösungen per se eine Hintertür.
“All right, then, I'll go to hell.” – Huck Finn
Auge
Camping_RIDER
Gunnar Bittersmann