heißen, denn ansonsten kann es zu fehlenden Semikola und damit Parsing-Problemen führen.
Außerdem überschreibt document.cookie = cook; jedes mal den Cookie und fügt nicht neue Attribute hinzu. Damit enthält der Cookie immer nur das letzte Attribut, das du "hinzugefügt" hast.
if(cookieContent.search(replaceString) == -1){
macht keinen Sinn.
cookieContent.search(replaceString)
sollte
replaceString.search(replaceAttr)
heißen, denn replace() verändert nicht den String, auf dem es angewendet wird, sondern gibt einen neuen String zurück, der aus dem alten inklusive den Veränderungen (falls etwas verändert wurde) besteht. Weiter gibt search() nur in dem Fall -1 zurück, wenn die Suche nicht erfolgreich war, du musst also nicht auf Gleichheit, sondern auf Ungleichheit prüfen. Damit sollte die Zeile, soweit ich das sehe
if(replaceString.search(replaceAttr) != -1){
heißen.
Edit: Mit JSON könntest du dir übrigens das Leben auch einfacher machen.
heißen, denn ansonsten kann es zu fehlenden Semikola und damit Parsing-Problemen führen.
...
Anscheinend ist leider beides falsch. Das Expire Attribut scheint gar nicht im eigentlich Wert vorkommen zu dürfen. Ich werd es von daher mal hinten drancaten.
Zitat von Kyuu
Außerdem überschreibt document.cookie = cook; jedes mal den Cookie und fügt nicht neue Attribute hinzu. Damit enthält der Cookie immer nur das letzte Attribut, das du "hinzugefügt" hast.
...
Nein. Ein Cookie verhält sich nicht wie ein normaler String. Es ist ja wie gesagt auch die Sache das das bis dahin wunderbar funktioniert. Es werden mit der Methode genau auf dem Wege zwei Cookies erstellen. Ja, zwei verschiedene. Wie gewollt also eigentlich. Soweit ich mir das vorhin angelesen habe, scheint man bei einem Cookie eher Zugriff auf die Paare von Werten. Auch wenn man es , zumindestens theoretisch, als String behandeln kann.
Zitat
if(cookieContent.search(replaceString) == -1){
macht keinen Sinn.
cookieContent.search(replaceString)
sollte
replaceString.search(replaceAttr)
heißen, denn replace() verändert nicht den String, auf dem es angewendet wird, sondern gibt einen neuen String zurück, der aus dem alten inklusive den Veränderungen (falls etwas verändert wurde) besteht. Weiter gibt search() nur in dem Fall -1 zurück, wenn die Suche nicht erfolgreich war, du musst also nicht auf Gleichheit, sondern auf Ungleichheit prüfen. Damit sollte die Zeile, soweit ich das sehe
if(replaceString.search(replaceAttr) != -1){
heißen.
...
Doch, das hat schon so seinen Sinn.
Im replaceString befindet sich der neu zu setzende String. Heisst also die Abfrage soll abfragen ob die zwei Strings eben nicht dem anderen gleichen. Wenn nämlich der Original Inhalt in cookieContent dem Inhalt von replaceString gleicht, dann wurde in replaceString keine Ersetzung vorgenommen. Ist quasi als Sicherheitsabfrage gedacht.
Das replace() nur einen String zurückliefert und nicht automatisch etwas verändert ist mir bekannt. Anders benutze ich es ja im Code auch nirgendwo.
Zitat
Edit: Mit JSON könntest du dir übrigens das Leben auch einfacher machen.
...
Dankeschön, sieht nützlich aus. Ist aber wahrscheinlich nichts was ich im aktuellen Projekt einbinden darf. Die Aufgabenstellung ist reiner eigener Code. Keine fremden Biblotheken oder ähnliches.
Also alles in allem scheint das Problem daran zu liegen das ich auf die Wertepaare falsch zugreife. So wie es aussieht kann ich den Cookie nicht als normalen String sehen. http://www.quirksmode.org/js/cookies.html <-- Zumindestens hier nach.
Nein. Ein Cookie verhält sich nicht wie ein normaler String. Es ist ja wie gesagt auch die Sache das das bis dahin wunderbar funktioniert. Es werden mit der Methode genau auf dem Wege zwei Cookies erstellen. Ja, zwei verschiedene. Wie gewollt also eigentlich. Soweit ich mir das vorhin angelesen habe, scheint man bei einem Cookie eher Zugriff auf die Paare von Werten. Auch wenn man es , zumindestens theoretisch, als String behandeln kann.
...
Ok, da zeigt sich, dass ich kein Webentwickler bin. Aber dennoch möchte ich kommentieren, dass ich dieses kontraintuitive Verhalten äußerst dämlich finde. Wenn ich a gleich b setze, erwarte ich, dass a im Nachhinein auch gleich b ist. Wer auch immer dafür verantwortlich ist, sollte sich in Grund und Boden schämen.
Zitat von makenshi
Doch, das hat schon so seinen Sinn.
Im replaceString befindet sich der neu zu setzende String. Heisst also die Abfrage soll abfragen ob die zwei Strings eben nicht dem anderen gleichen. Wenn nämlich der Original Inhalt in cookieContent dem Inhalt von replaceString gleicht, dann wurde in replaceString keine Ersetzung vorgenommen. Ist quasi als Sicherheitsabfrage gedacht.
...
Da wären wir wieder bei kontraintuitivem Verhalten. ;) Dass du da das Pferd von hinten aufzäumst, fällt beim ersten Blick nicht auf. Was man da erwartet, ist, dass replaceString auf ein Vorkommen von replaceAttr überprüft wird (in welchem Fall eben eine Ersetzung stattfand). Wenn du wirklich die beiden Strings auf Un- bzw. Gleichheit überprüfen willst, wieso nicht einfach != bzw. == benutzen?
Zitat von makenshi
Also alles in allem scheint das Problem daran zu liegen das ich auf die Wertepaare falsch zugreife. So wie es aussieht kann ich den Cookie nicht als normalen String sehen. http://www.quirksmode.org/js/cookies.html <-- Zumindestens hier nach.
...
Alles was du nach dieser Seite beachten musst, ist wie Cookies gesetzt werden, also zum Beispiel, dass zur gleichen Zeit nur ein Wert gesetzt werden kann und ein bestimmtes Format eingehalten werden muss. document.cookie gibt ja immer noch einen vollwertigen String zurück, der aber natürlich etwas anders aufgebaut ist, als du gedacht hast.
Ok, da zeigt sich, dass ich kein Webentwickler bin. Aber dennoch möchte ich kommentieren, dass ich dieses kontraintuitive Verhalten äußerst dämlich finde. Wenn ich a gleich b setze, erwarte ich, dass a im Nachhinein auch gleich b ist. Wer auch immer dafür verantwortlich ist, sollte sich in Grund und Boden schämen.
...
Kein Ding, ich bin davon genau so vom Blitz getroffen worden. Anscheinend werden da auf irgendeine kranke Art und Weise setter aufgerufen die die entsprechenden Attribute dann setzen. Sowas kann ich auch absolut nicht nachvollziehen.
Zitat
Da wären wir wieder bei kontraintuitivem Verhalten. Dass du da das Pferd von hinten aufzäumst, fällt beim ersten Blick nicht auf. Was man da erwartet, ist, dass replaceString auf ein Vorkommen von replaceAttr überprüft wird (in welchem Fall eben eine Ersetzung stattfand). Wenn du wirklich die beiden Strings auf Un- bzw. Gleichheit überprüfen willst, wieso nicht einfach != bzw. == benutzen?
...
Wo du natürlich Recht hast. x)
Das ist glaube ich an sich meine stellenweise verdrehte Logik.
Besser wäre es aber definitiv den veränderten String auf ein Vorkommen von replaceAttr zu überprüfen. Werd ich denk ich morgen auch mal umändern.
Zitat
Alles was du nach dieser Seite beachten musst, ist wie Cookies gesetzt werden, also zum Beispiel, dass zur gleichen Zeit nur ein Wert gesetzt werden kann und ein bestimmtes Format eingehalten werden muss. document.cookie gibt ja immer noch einen vollwertigen String zurück, der aber natürlich etwas anders aufgebaut ist, als du gedacht hast.
...
Naja, an sich dürfte es dem Cookie hoffentlich egal sein wie ich den Wert zusammenbaue. Solange ich keine Delimiter benutze die der Cookie benutzt. Hoffe ich. Ich werd auf jeden Fall morgen schauen das ich den Cookie anständig generiert bekomme. Mithilfe der Informationen von der Seite dürfte das aber einfach werden.
Vielleicht bemerke ich bei der Gelegenheit dann auch wodran die vorherige Methode scheiterte. Ich schätz aber simpel am bereits vorliegenden Aufbau der Cookies.
Naja, an sich dürfte es dem Cookie hoffentlich egal sein wie ich den Wert zusammenbaue. Solange ich keine Delimiter benutze die der Cookie benutzt. Hoffe ich.
...
Klar. Ich meinte eher sowas wie document.cookie = "attr1=val1; attr2=val2; ...". ;)
Falls du noch nicht herausgefunden hast, woran das Ersetzen scheiterte:
versuchst zu speichern. Das Problem ist nun (wie aus der von dir gelinkten Seite hervorgeht), dass der interne Cookie-Setter nur Strings der Form "name=value; expiry=... ; path=..." akzeptiert, das heißt, es gehen alle Name-Value-Paare nach dem ersten Name-Value-Paar verloren und damit kann auch immer nur das erste Name-Value-Paar verändert werden. Die Lösung ist denkbar einfach: extrahiere das gewünschte Name-Value-Paar aus dem String, der vom Cookie-Getter zurückgegeben wird und arbeite damit weiter.