Wertübergabe weiterentwickeln - JavaScripter gesucht!
molily
Wertübergabe weiterentwickeln - JavaScripter gesucht!
molily
Hallo Leute,
vielleicht kennt ihr den Artikel Wertübergabe mit JavaScript. Ich wünsche mir, dass den jemand weiterentwickelt. Was derzeit nur im Ausblick steht, kann man mittlerweile schon praktisch anwenden.
Ich habe ein robustes und zukünftsfähiges Fertigscript vor Augen, mit dem man komplexere Daten übertragen kann und die dazu nötigen Techniken je nach Verfügbarkeit gewählt werden - also eine Rundum-Sorglos-Allround-Lösung.
Meine Ideen:
Man übergibt z.b. storage.set ein Object-Literal:
storage.set({ name1 : "wert1" });
storage.set({ name2 : "wert2", name3 : "wert3" });
Alle Member werden dann in den »Speicher« kopiert.
Die Folgeseite soll das Namen-Werte-Paar nun auslesen können, z.B. storage.get("name") oder storage.getAll würde ein Object mit allen Membern ergeben. Über die interne Funktionsweise muss sich der Anwender keine Gedanken machen.
Zur Übertragung wird in erster Linie HTML 5 sessionStorage verwendet.
Steht das nicht zur Verfügung, werden Session-Cookies verwendet.
Kann kein Session-Cookie gesetzt werden bzw. wurde er abgelehnt, wird window.name verwendet.
Für Cookies und window.name wird das Object mit mit JSON serialisiert und ggf. kodiert, um in den Cookie-Wert zu passen. Dazu kann das Script native JSON-Implementierungen verwenden. Falls diese noch nicht zur Verfügung stehen, wird Douglas Crockfords JSON-Implementierung in JavaScript eingebunden (das Script kann »minified« mitgeliefert werden).
Letztlich müsste man sich über Sicherheitsfragen Gedanken machen, z.B. standardmäßig beim Auslesen den Speicher leeren - zumindest bei window.name.
Es wäre toll, wenn jemand ein solches oder ähnliches Fertigscript schreiben könnte, sodass wir es auf SELFHTML aktuell im Rahmen eines Artikels veröffentlichen können.
Mathias
-
Lieber molily,
ich habe für mich aus diesem Artikel die ein oder andere Idee abgeleitet, und für mich ein Script geschrieben, das Daten für eine ganz bestimmte Anwendung zwischen Fenstern austauscht.
Das Script kann man sozusagen live in Aktion betrachten, wenn man sich diesen kleinen erzählenden Hypertext anschaut: Save The Crown Jewels.
Das Kernstück sind zwei Funktionen, die ein Objekt serialisieren, und wieder entserialisieren. Der so erzeugte String wird in window.name abgelegt. Suchst Du in etwa sowas? Natürlich dann für beliebig tief verschachtelte Objekte...?
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)-
Danke, das werde ich mir mal anschauen.
Das Kernstück sind zwei Funktionen, die ein Objekt serialisieren, und wieder entserialisieren. Der so erzeugte String wird in window.name abgelegt. Suchst Du in etwa sowas? Natürlich dann für beliebig tief verschachtelte Objekte...?
Ja, ich will aber nicht das Rad neu erfinden.
window.name ist m.M.n. die schlechteste Möglichkeit. Sie ist unsicher (keine Same-Origin-Policy) und man muss die Daten serialisieren. Deshalb hatte ich die Idee, in erster Linie auf DOM Storage zu setzen. Wenn das nicht verfügbar ist und eine Serialisierung nötig ist, nimmt man JSON statt eigene beschränkte Serialisierungsfunktionen. Das werden in Zukunft alle Browser nativ können, daher ist es Zeit, bei jeglicher Serialisierung auf diese Standardlösung zu setzen, die einfach am flexibelsten und erprobtesten ist.Mathias
-
Lieber molily,
Ja, ich will aber nicht das Rad neu erfinden.
klar.
window.name ist m.M.n. die schlechteste Möglichkeit. Sie ist unsicher (keine Same-Origin-Policy) und man muss die Daten serialisieren.
Vielleicht ist das transportieren der Daten über window.name nicht unbedingt sicher, aber welche Notwendigkeit besteht denn hier für Sicherheit? Wer muss denn mit JavaScript Daten unbedingt "sicher" von einem Dokument zum anderen transportieren? Die Anwendungsfälle dafür scheinen mir nicht sicherheitsrelevant zu sein, denn wer es sicher braucht, der macht das mit einer Session, die dann serverseitig gesteuert wird.
Deshalb hatte ich die Idee, in erster Linie auf DOM Storage zu setzen. Wenn das nicht verfügbar ist und eine Serialisierung nötig ist, nimmt man JSON statt eigene beschränkte Serialisierungsfunktionen.
Meine Serialisierungen erzeugen JSON Strings! Die so notierten Objekte stehen nach der De-Serialisierung wieder zur Verfügung.
Das werden in Zukunft alle Browser nativ können, daher ist es Zeit, bei jeglicher Serialisierung auf diese Standardlösung zu setzen, die einfach am flexibelsten und erprobtesten ist.
Ich werde mich wohl mal über DOM Storage erkundingen müssen - aber nicht heute.
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
-
-
-
Alles muss man selber machen! ;)
http://aktuell.de.selfhtml.org/artikel/javascript/wertuebergabe/storage2.js
http://aktuell.de.selfhtml.org/artikel/javascript/wertuebergabe/storage2-app.htmlIst erstmal das Gerüst, noch nicht ganz durchgetestet. Cookie + json2.js scheint schon zu funktionieren, interessant wirds bei sessionStorage bzw. Cookie/window.name + nativem JSON (wobei letzteres eigentlich unwahrscheinlich ist - welcher Browser kann natives JSON, aber kein Session Storage?).
Mitstreiter können sich gerne einklinken, Vorschläge und Kritik sind erwünscht!
Mathias