nicht angemeldet
local storage
TS
JürgenBHallo,
wie kann ich einen PHP Array in einem local storage speichern um später darauf auch wieder zugreifen zu können?
Meine Werte kommen aus
$kat = array();
$kat = $_GET["kat"];
Bis bald!
Meowsalot (Bernd)
-
Tach!
wie kann ich einen PHP Array in einem local storage speichern um später darauf auch wieder zugreifen zu können?
Gar nicht. PHP ist auf dem Server, Local Storage ist auf dem Client. Um Daten auf dem Server für einen Besucher zu speichern nimm eine Session. Für Daten, die auf dem Client für die Javascript-Verarbeitung zu speichern sind, ist der Local Storage geeignet. Da er ein sehr einfacher Key-Value-Speicher ist, kann man komplexe Strukturen nur serialisiert ablegen, beispielsweise JSON.
dedlfix.
-
Hallo dedlfix,
Gar nicht. PHP ist auf dem Server, Local Storage ist auf dem Client. Um Daten auf dem Server für einen Besucher zu speichern nimm eine Session.
das war meine erste Idee, allerdings wenn der Browser geschlossen wird ist die Session weg und der User muss seine Auswahl wieder von vorne tätigen. Ist etwas Bebnutzerunfreundlich? Oder soll ich die Einstellungen lieber in einer Datenbank speichern? Wäre wohl der beste Fall?
Bis bald!
Meowsalot (Bernd)-
Hello,
[...] allerdings wenn der Browser geschlossen wird ist die Session weg
Das hängt immer von der Wahl der Cookies ab und wie die Sessiondaten überhaupt gespeihcert werden. Bei Simple-PHP-Sessions sind diese solange verfügbar, bis sie gezielt gelöscht werden oder der Müllaufräumer die Sessiondatei besetigt hat. Das kann Tage dauern.
Zugreifen kann das passende Serverprogramm (Skript) immer dann darauf, solange es das Token (Session-Key) kennt. Wie das von einem Roundturn zum nächsten übermittelt werden kann, ist durchaus vielfältig.
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
hallo
das war meine erste Idee, allerdings wenn der Browser geschlossen wird ist die Session weg und der User muss seine Auswahl wieder von vorne tätigen. Ist etwas Bebnutzerunfreundlich? Oder soll ich die Einstellungen lieber in einer Datenbank speichern? Wäre wohl der beste Fall?
Die Frage ist, geht es um Browserdata, oder geht es um User-Data. local-storage kann man kaum als user-storage bezeichnen.
-
Tach!
Um Daten auf dem Server für einen Besucher zu speichern nimm eine Session.
das war meine erste Idee, allerdings wenn der Browser geschlossen wird ist die Session weg
Man kann den Session-Cookie auch so einstellen, dass er länger hält.
und der User muss seine Auswahl wieder von vorne tätigen. Ist etwas Bebnutzerunfreundlich?
Ich kann dir nicht raten, was du nehmen solltest, weil ich den Anwendungsfall nicht kenne.
dedlfix.
-
-
-
Hallo,
wie kann ich einen PHP Array in einem local storage speichern um später darauf auch wieder zugreifen zu können?
Meine Werte kommen aus
$kat = array(); $kat = $_GET["kat"];Also vom Browser. Und wenn sie auch dort bleiben sollen, ist localStorage genau der richtige Ort dafür. Da kannst Du ein Array auf 2 verschiedene Art und Weise speichern:
1. assoziativ (Schlüssel bzw. Index, Werte), 2. serialisiert(Schlüssel, JSON).(1) wenn es nur das Array zu speichern gibt, bei (2) musst Dir selbst einen Schlüssel festlegen. localStorage ist an den URL gebunden, ganz ähnlich wie ein Cookie.
MfG
PS: Gute Idee übrigens, weil es die Benutzerfreundlichkeit verbessert.
-
Tach!
Da kannst Du ein Array auf 2 verschiedene Art und Weise speichern:
1. assoziativ (Schlüssel bzw. Index, Werte), 2. serialisiert(Schlüssel, JSON).Der LocalStorage ist lediglich ein einzelner Key-Value-Speicher. Man kann darin nicht mehrere Tabellen anlegen, wie in einer Datenbank beispielsweise. Es ist deshalb empfehlenswert, zusammengehörende Dinge zusammenzufassen und unter einem Key abzulegen.
Der LocalStorage ist kein Array. Der Zugriff auf den Inhalt erfolgt über Methoden des Storage-Interfaces, hauptsächlich
getItem('key'),setItem('key', value). (Ja, auch localStorage.key und localStorage['key'] sind möglich, ist aber im MDN wegen Nebenwirkungen in bestimmten Fällen nicht empfohlen.) Man kann zwar ein Javascript-Array oder ein Objekt auseinandernehmen und für jeden Eintrag oder jede Eigenschaft ein Key-Value-Paar im LocalStorage ablegen, aber das ist nicht gerade günstig, falls man später auf die Idee kommt, weitere Dinge dort ablegen zu wollen. Man könnte in Konflikt mit den Keys kommen. Zudem ist unnötig umständlich alle Einträge einzeln über die beiden Methoden anzusprechen. Deswegen lieber die eigene Datenstruktur serialisieren und als ein Eintrag im LocalStorage ablegen. Geht auch als Zweizeiler (serialisieren + speichern und holen + deserialisieren) einfacher, als jeden Wert extra zu behandeln.Zudem sind wir hier auf dem Client und in Javascript, da gibt es Arrays oder Objekte. Arrays haben nur numerische Indexe. Anstelle von assoziativen Arrays, wie man sie aus PHP kennt, kann man nur Objekte nehmen.
Weiterhin ist noch gar nicht mal klar, was der OP überhaupt und eigentlich braucht. Eine PHP-Datenstruktur im Client zu speichern, um sie in PHP weiterzuverarbeiten, ist ziemlich umständlich, zumal er auf diese Idee ja nur kam, weil er mit der Laufzeit des Session-Cookies ein Problem hat.
localStorage ist an den URL gebunden, ganz ähnlich wie ein Cookie.
LocalStorage ist lediglich an die Domain gebunden. Die weiterreichenden Einstellmöglichkeiten von Cookies (Subdomains, Path) stehen nicht zur Verfügung.
P.S. Alle Ausführungen gelten auch für SessionStorage, das sich nur in der Aufbewahrungsdauer der Daten vom LocalStorage unterscheidet.
dedlfix.
-
Noch was zu (2), falls Du einen Serializer hast, welche die Fomularfelder für
application/x-www-form-urlencodedprozentkodiert auch deserialisieren kann, wäre es naheliegend, das ganze Formular auf diese Art serialisiert in localStorage abzulegen. Für den Schlüssel empfiehlt es sich, den URL der Seite selbst zu nehmen, aber das ist dann eher eine praktische Frage (evntl. auch die id des Formulars).Einfach mal machen, da siehst Du am Besten was zweckmäßig ist.
MfG
-
Hallo Rolf,
… Für den Schlüssel empfiehlt es sich, den URL der Seite selbst zu nehmen, …
da der local Storage an den URL gekoppelt ist, wäre das so, als würde ich die Wohnungstür im Haus „Grüne Allee 42“ mit „Grüne Allee 42“ beschriften. 😎
Gruß
Jürgen-
hi Jürgen,
… Für den Schlüssel empfiehlt es sich, den URL der Seite selbst zu nehmen, …
da der local Storage an den URL gekoppelt ist, wäre das so, als würde ich die Wohnungstür im Haus „Grüne Allee 42“ mit „Grüne Allee 42“ beschriften. 😎
Es ist eine praktische Frage, also eine Frage der Skalierbarkeit und Wartungsfreundlichkeit. Wenn der URL ohnehin in einem Platzhalter steht, sieht der Schlüssel in Code bspw. so aus:
%url%#123wenn 123 die id des Formulars ist. So ergibt sich die Absicht dessen was der CODE machen soll aus der nächsten Zeile wenn der gespeicherte Wert in ein Objekt zurückverwandelt wird (deserialize).Und damit ist sowas auch Tage später nachvollziehbar ohne 3 Seiten Kommentar darüber lesen zu müssen.
MfG
-
Tach!
da der local Storage an den URL gekoppelt ist,
Domain, nicht URL. Cookies kann man nach Subdomain und Path einschränken, LocalStorage nicht.
dedlfix.
-
-
Tach!
Noch was zu (2), falls Du einen Serializer hast, welche die Fomularfelder für
application/x-www-form-urlencodedprozentkodiert auch deserialisieren kann, wäre es naheliegend, das ganze Formular auf diese Art serialisiert in localStorage abzulegen.Das sieht mir ziemlich wenig praktikabel aus. Soweit bisher bekannt ist, sollen dem Anwender die Eingabedaten nicht verlorengehen. Das heißt, man braucht sie in Rohform, um sie als Werte wieder in die Eingabefelder schreiben zu können. Sie als FormData abzulegen, ergibt keinen Nutzen gegenüber einem einfachen Objekt, das mit JSON serialisiert wird. Die Browserkompatibilität von FormData lässt ebenfalls zu wünschen übrig.
Das Absenden erfolgt erst später, wozu die Daten der Eingabefelder sowieso in ein neues FormData-Objekt gebracht werden, falls Ajax verwendet wird und nicht der herkömmliche Formularmechanismus. Das bisherige FormData ist also nicht weiter verwendbar.
dedlfix.
-
Es ist eine Frage wie man seinen CODE organisiert. Und wenn ein Formular ohnehin serialisiert wird, bietet es sich an es auch ebenso zu speichern. Im Übrigen ist es recht einfach aus dem Enctype="application/x-www-form-urlencoded" ein Objekt zu machen und umgekehrt. Zumal für die Prozentkodierung JS selbst zwei objektunabhängige Funktionen mitbringt.
Aber letztendlich ist es Praxis. Die muss sich jeder selbst erarbeiten. MfG
-
Tach!
Es ist eine Frage wie man seinen CODE organisiert. Und wenn ein Formular ohnehin serialisiert wird, bietet es sich an es auch ebenso zu speichern. Im Übrigen ist es recht einfach aus dem Enctype="application/x-www-form-urlencoded" ein Objekt zu machen und umgekehrt. Zumal für die Prozentkodierung JS selbst zwei objektunabhängige Funktionen mitbringt.
Prinzipiell ja, nur stellt sich mir die Frage, warum man in seiner Anwendung etwas wählen sollte, das für den Transport vorgesehen, ansonsten aber für das normale Arbeiten wenig geeignet ist. In meiner Javascript-Welt möchte ich vorwiegend mit den dort vorhandenenen nativen Elementen arbeiten. Darauf setzt alle mögliche grundlegende Funktionalität auf, ohne dass man die Besonderheiten prozentkodierter Dinge beachten muss. Mit prozentkodierten Daten zu hantieren bringt da keine Vorteile, eher im Gegenteil. Dass man hin- und herkodieren kann ist schön und gut. Wenn ich native Objekte nehme, habe ich dafür jedoch keine Notwendigkeit, außer wenn es denn wirklich um den Transport geht.
dedlfix.
-
Tach!
Es ist eine Frage wie man seinen CODE organisiert. Und wenn ein Formular ohnehin serialisiert wird, bietet es sich an es auch ebenso zu speichern. Im Übrigen ist es recht einfach aus dem Enctype="application/x-www-form-urlencoded" ein Objekt zu machen und umgekehrt. Zumal für die Prozentkodierung JS selbst zwei objektunabhängige Funktionen mitbringt.
Prinzipiell ja, nur stellt sich mir die Frage, warum man in seiner Anwendung etwas wählen sollte, das für den Transport vorgesehen, ansonsten aber für das normale Arbeiten wenig geeignet ist.
Weil Transport und Speicherung im Grunde genau dasselbe ist. Nicht nur theoretisch sondern auch praktisch. Wohingegen die "normale Arbeit" den wahlfreien Zugriff auf die einzelnen Elemente einer Datenstruktur benötigt.
In meiner Javascript-Welt möchte ich vorwiegend mit den dort vorhandenenen nativen Elementen arbeiten.
Genau. Und genau dafür bietet sich ein Objekt an, so ist z.B. der Input/Vorname im Objekt
formperform.vornamedirekt adressierbar (random access, wahlfreier Zugriff).Mit prozentkodierten Daten zu hantieren bringt da keine Vorteile, eher im Gegenteil.
Die Prozentkodierung ist völlig uninteressant. Sie ist transparent.
MfG
-
-
hallo
Es ist eine Frage wie man seinen CODE organisiert. Und wenn ein Formular ohnehin serialisiert wird, bietet es sich an es auch ebenso zu speichern.
Von wem wird es gespeichert? Wer wird es als erstes wieder anfordern?
-
hallo
Es ist eine Frage wie man seinen CODE organisiert. Und wenn ein Formular ohnehin serialisiert wird, bietet es sich an es auch ebenso zu speichern.
Von wem wird es gespeichert? Wer wird es als erstes wieder anfordern?
Das ist eine Frage der Programmlogik. Und eng verbunden damit auch eine Frage der Praxis. Also, wenn bspw. bestimmte Felder eines Formulars ausgefüllt sein sollen, wird man da am Besten ein Template verwenden und die entsprechenden Platzhalter da einsetzen.
Mf
-
hallo
hallo
Es ist eine Frage wie man seinen CODE organisiert. Und wenn ein Formular ohnehin serialisiert wird, bietet es sich an es auch ebenso zu speichern.
Von wem wird es gespeichert? Wer wird es als erstes wieder anfordern?
Das ist eine Frage der Programmlogik. Und eng verbunden damit auch eine Frage der Praxis. Also, wenn bspw. bestimmte Felder eines Formulars ausgefüllt sein sollen, wird man da am Besten ein Template verwenden und die entsprechenden Platzhalter da einsetzen.
Mf
Ich hätte die Antwort javascript erwünscht. Wir verlassen gar nie den Kontext von Javascript, und es gibt hier gar keinen Kontextwechsel, abgesehen von der Serialisierung für die sich hier sowieso JSON.stringify anbietet.
Platzhalter in html haben nicht die Rolle von default-values. Und default-values sind wiederum etwas anderes als user-set-values.
Wir wissen immer noch nicht den konkreten Anwendungszweck. Aber local-storage ist in keiner Weise auf das Zwischenspeichern von Formulardaten beschränkt.
Hier sind Anwendungen wo ich local-storage für richtig halte. Daten die in Bezug zum Agent stehen, die der User sehr wahrscheinlich für dieses Gerät einmal anpasst und dann selten ändern wird:
- Angaben zum bevorzugten Input-device
- User-Language
- Tastaturkürzel
-
hallo
hallo
Es ist eine Frage wie man seinen CODE organisiert. Und wenn ein Formular ohnehin serialisiert wird, bietet es sich an es auch ebenso zu speichern.
Von wem wird es gespeichert? Wer wird es als erstes wieder anfordern?
Das ist eine Frage der Programmlogik. Und eng verbunden damit auch eine Frage der Praxis. Also, wenn bspw. bestimmte Felder eines Formulars ausgefüllt sein sollen, wird man da am Besten ein Template verwenden und die entsprechenden Platzhalter da einsetzen.
Mf
Ich hätte die Antwort javascript erwünscht.
Auch für JS gibt es Templating Engines. Da kriegt die renderFunktion das Template und das Objekt mit den Daten und was dann sichtbar wird, entscheidet nur der Platzhalter, also ob es bspw. für Name und Vorname Platzhalter gibt oder nicht. Das ist ja der Vorteil einer TE, daß man solche Sachen dann außerhalb vom CODE regeln kann.
Ob das Objekt aus JSON wiederhergestellt wird oder aus einem anderen Enctype ist da völlig uninteressant.
MfG
-
-
-
-
-
-