ChrisB: Ajax no good / DOM Storage als mögliche Alternative

Beitrag lesen

Hi,

Ich könnte mir beides *ohne* AJAX vorstellen.

Ja, ich eigentlich auch. Aber AJAX läuft so schön im Hintergrund ist ist doch so modern ;)
Ist AJAX denn ein Problem?

Ja, es verkompliziert die Sache unnötig.

Wenn du im ersten Schritt die Formulardaten per AJAX zum Server schickst, dann landet dessen Antwort darauf auch „im JavaScript“ - und damit hast du wiederum keine Möglichkeit, sie direkt auf Platte abzulegen oder den Speichern-Dialog aufzurufen. Klar, du könntest nach dem Request per location.href auf eine Adresse „umleiten“, unter der der Server die Daten dann mit passendem Content-Type-Header wieder ausgibt, und so den Speichern-Dialog provozieren - aber das wären zwei Requests statt einem, und du müsstest die Daten serverseitig auch noch zwischenspeichern (Session o.ä.).

Schickst du stattdessen ganz normal ein Formular an den Server ab, kann dieser darauf direkt mit der Ausgabe (bzw. Rückgabe, mehr ist es ja eigentlich nicht) nach einem passenden Content-Type-Header antworten - Speichern-Dialog erscheint, alles fein, kaum Aufwand verglichen mit obigem.

Und auch der umgekehrte Weg ist komplizierter (bis unmöglich), wenn man dafür auf Teufel komm raus AJAX einsetzen wollte. Klar, du kannst mit einem File-Inputfeld eine Datei vom lokalen Rechner auswählen lassen - aber du hast mit JS unter normalen Umständen keinen Zugriff auf den Inhalt dieser Datei, also kannst du ihn auch nicht per AJAX zum Server schicken. (Dass es in manchen Browsern inzwischen Möglichkeiten gibt, das unter bestimmten Umständen [Sicherheitseinstellungen] bzw. mit bestimmten Zusatztechniken [JAVA, Flash, Active-X] trotzdem zu realisieren, ist schön und gut - aber einen so simplen Vorgang wie den hier derart zu komplizieren und damit von noch mehr äusseren Faktoren abhängig und somit fehleranfälliger zu machen, kann ja kaum Sinn der Sache sein.)

Nimmst du auch hier wieder ein stinknormales Upload-Formular, kann der Nutzer seine gespeicherten Daten simpel an den Server senden, dieser bereitet sie auf, und erstellt ein Antwortdokument, in dem sie an den passenden Stellen bereits eingetragen sind - viel simpler geht's nicht.

Zwar ist es natürlich auch nicht das „Gelbste vom Ei“, die Daten zur Speicherung erst vom Client an den Server und wieder zurück zu schicken, und zum Laden noch mal das gleiche in grün - aber es ist eine sehr simple, einfach realisierbare und im Vergleich zu Alternativen wenig fehlerträchtige Methode, und da es sich hier nur um „ein paar Datensätze“ handeln soll laut Problembeschreibung, dürften zusätzlicher Traffic und Zeitbedarf auch akzeptabel sein unter den vorliegenden Bedingungen.

Natürlich geht dieser Weg nur so lange, wie die Applikation nur dann verfügbar sein muss, wenn der Nutzer auch online ist.
Soll das ganze lokal ablaufen (und auch die Berechnungen nur lokal per Script vorgenommen werden), dann müsste man sich etwas anderes überlegen.

Dann (nicht *nur* dann) wäre überlegenswert, ob man das ganze auch mittels DOM Storage erledigen könnte. Die Verfügbarkeit ist in aktuellen Browsern ja auch recht gut, und man unterliegt weniger Einschränkungen (bspw. hinsichtlich Datenmenge) als bei Nutzung von herkömmlichen Cookies.

MfG ChrisB

--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]