nicht angemeldet
Variablen über Reload hinweg behalten
Hallo!
In einer Javascript-/Ajax-lastigen Anwendung lade ich über Ajax einiges an Daten vom Server. Diese Daten ändern sich nur relativ selten. Nun suche ich nach einer Möglichkeit, diese Daten auch bei einem Reload im Client zu halten, so dass sie nicht jedesmal neu geladen werden müssen. (Das Problem, dass sich die Daten eben doch mal ändern könnten, ignoriere ich vorläufig.)
Wenn ich die Daten in einer Javascript-Variablen speichere, ist diese nach dem Reload natürlich leer. Nun hatte ich die Idee, die Daten an eines der Standard-Objekte (window, navigator, ...) zu hängen. Im Firefox funktioniert das auch tatsächlich: Wenn ich "navigator.foo = 42" schreibe, dann ist der Wert nach dem Reload noch da. Im IE (getestet mit Version 7) klappt das nicht, d.h. anscheinend werden alle Objekte beim Reload zurückgesetzt.
Cookies scheiden m.E. aufgrund der Datenmenge aus. Ich hatte noch die Idee, ein Frameset mit einem unsichtbaren Frame (Breite/Höhe = 0) zu machen und die Daten dort zu hinterlegen. Die Lösung gefällt mir aber eigentlich nicht so, da mich das Frameset stört (z.B. Anzeige der URL).
Kennt jemand eine andere/bessere Möglichkeit, Daten im Client über einen Reload hinweg zu speichern?
Vielen Dank schon mal vorab für Eure Hilfe!
Christian
-
Hallo,
Kennt jemand eine andere/bessere Möglichkeit, Daten im Client über einen Reload hinweg zu speichern?
Du könntest Flashcookies (Local Shared Objects) benutzen. Haben etwas mehr Speicherplatz per Default (1MB soviel ich weiß) und theoretisch beliebig viel (wird dann vom Flash-Plugin beim Benutzer angefordert).
Nachteil: User braucht mindestens Flash 6, muss die Nutzung von Flashcookies zulassen (ist zwar per default an, aber kann man auch abschalten) und die Kommunikation JavaScript<->Flash ist ja immer so ne Sache. Auch unter dem Sichehreitsaspekt nicht ganz ohne (Flashcookies werden von den meisten Browser-Standard-Privatsphären-Einstellungen ignoriert).
Aber vielleicht kannst Du's ja brauchen.
Viele Grüße,
Jörg-
Du könntest Flashcookies (Local Shared Objects) benutzen.
Ein bisschen anderer Ansatz (nicht nur Dokument-, sondern Session-übergreifend), aber ein Wrapper u.a. für Flash-Supercookies:
PersistJSMathias
-
-
Kennt jemand eine andere/bessere Möglichkeit, Daten im Client über einen Reload hinweg zu speichern?
http://aktuell.de.selfhtml.org/artikel/javascript/wertuebergabe/ schneidet bereits Techniken wie sessionStorage und userData an. Das Script storage2 implementiert diese als Wrapper. Die entstehende Doku, noch ein ziemliches Durcheinander. Ein Beispiel für die Benutzung der Bibliothek.
Mathias
-
-
[latex]Mae govannen![/latex]
Ein ähnliches Projekt:
JSS is a lightweight javascript library that brings client side session functionality to your web applications.Nutzt leider an mehreren Stellen Browsersniffing und ohne Abfrage auf Existenz console.log, das nicht in allen Browsern verfügbar ist. (vermutlich debug-leftover) Zumindest letzteres sollte man bei dieser Version vor Benutzung auskommentieren.
Cü,
Kai
--
Ash nazg durbatulûk, ash nazg gimbatul,ash nazg thrakatulûk, agh burzum-ishi krimpatul
SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?-
Nutzt leider an mehreren Stellen Browsersniffing
Meinst du isCompatible für userData? Mag sein, dass das unnötig ist, bei mir verwende ich schlicht Boolean(document.documentElement.addBehavior).
Mathias
-
[latex]Mae govannen![/latex]
Nutzt leider an mehreren Stellen Browsersniffing
Meinst du isCompatible für userData? Mag sein, dass das unnötig ist, bei mir verwende ich schlicht Boolean(document.documentElement.addBehavior).
Das und auch JSS.SharedObject.isCompatible.
} else if (navigator.appVersion.indexOf("Mac") == -1 && window.execScript) {Dir muß ich die Probleme von Sniffing sicherlich nicht erklären, aber um das grundsätzliche Problem solcher Konstrukte noch mal anzusprechen:
Was passiert, wenn ein hypothetisch in ein paar Jahren erscheinender Browser mit Namen "Macabre" auf einmal rasend populär wird, dieser aber mit einer in diesem Zweig vorkommenden Methode nichts anzufangen weiß? Script-Abbruch, auch alle weitere Funktionalität des Scripts ist damit nicht mehr verfügbar. Also besser auf Verfügbarkeit der verwendeten Methoden testen.
(Dabei fällt mir ein, daß ich eigentlich schon seit einiger Zeit den hier gelegentlich auftretetenden Fehler (jetzt natürlich gerade nicht) in deinem Foren-Script jagen oder melden wollte, aber irgendwie kann ich mich aus persönlichen und technischen Gründen nicht wirklich dazu aufraffen. Mal sehen, irgendwann.)
Cü,
Kai
--
Ash nazg durbatulûk, ash nazg gimbatul,ash nazg thrakatulûk, agh burzum-ishi krimpatul
SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?-
Was passiert, wenn ein hypothetisch in ein paar Jahren erscheinender Browser mit Namen "Macabre" auf einmal rasend populär wird, dieser aber mit einer in diesem Zweig vorkommenden Methode nichts anzufangen weiß? Script-Abbruch, auch alle weitere Funktionalität des Scripts ist damit nicht mehr verfügbar. Also besser auf Verfügbarkeit der verwendeten Methoden testen.
Keine Ahnung, was der Autor da vorhat, aber ich vermute, in der Zeile wird bloß eine Prüfung auf den Internet Explorer vorgenommen. Da würde an der Stelle if (window.ActiveXObject) reichen), schließlich will man nur schauen, ob man ein Flash-Objekt instantiieren kann. Der Rest ist dann ohnehin in try-catch gekapselt, insofern wäre überhaupt keine Objektabfrage zwingend nötig.
Warum der Autor nun explizit den Mac als Plattform an dieser Stelle ausschließt - keine Ahnung.
Aber deine rhetorische Frage will ich gerne beantworten: Es passiert gar nichts, in appVersion steht kein Browsername. Und wenn doch "Mac" darin vorkommt, wird der Zweig einfach übersprungen und es wird angenommen, dass das Flash-Plugin nicht installiert ist. Klar kann das eine Fehlerkennung von Flash sein, aber das wars auch. Flash ist die letzte abgefragte Technik, wenn die vorher geprüften unterstützt werden, dann ist alles in Butter. Mein Script funktioniert ja ähnlich - wenn eine Erkennung fehlerhaft ist, geht nicht die Welt unter, sondern das Script läuft geordnet weiter bzw. beendet sich, wenn keine Technik erkannt wurde.
Mathias
-
[latex]Mae govannen![/latex]
Aber deine rhetorische Frage will ich gerne beantworten: Es passiert gar nichts, in appVersion steht kein Browsername.
Wieso habe ich da appName gelesen? Was man unbewußt lesen will ... Aber mir ging es ohnehin überhaupt nicht um diesen konkreten Fall, ich habe den Inhalt innerhalb der genannten Verzweigung nicht einmal genauer angeschaut, sondern um die generelle Warnung, Sniffing einzusetzen (was man IMO nicht oft genug machen kann)
Cü,
Kai
--
Ash nazg durbatulûk, ash nazg gimbatul,ash nazg thrakatulûk, agh burzum-ishi krimpatul
SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
-
-
-
-
-
-
-
hi,
Cookies scheiden m.E. aufgrund der Datenmenge aus.
Du musst ja nicht die gesamte Datenmenge in einem Cookie speichern. Es reicht, wenn der Zustand der letzten Benutzereingabe im Cookie gespeichert wird und somit bekäme ein Cookie auch einen Sinn.
Hotte
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.-
Cookies scheiden m.E. aufgrund der Datenmenge aus.
Du musst ja nicht die gesamte Datenmenge in einem Cookie speichern. Es reicht, wenn der Zustand der letzten Benutzereingabe im Cookie gespeichert wird und somit bekäme ein Cookie auch einen Sinn.
Nein, das reicht leider nicht. :-(
Das Problem ist ja, dass der Client diese ganzen Daten braucht. Es geht mir also gar nicht darum, den Zustand zu speichern, sondern wirkliche Nutzdaten. Allerdings wurden ja in den anderen Antworten tatsächlich einige interessante Möglichkeiten genannt.
-