nicht angemeldet
(ZU DIESEM FORUM) Cookies für's Forum
Hi allerseits,
ich habe inzwischen eine meiner Meinung nach recht optimierte, aber trotzdem kompatible und "saubere" Routine geschrieben, mit Hilfe derer sich dieses Forum sich via Cookie Name, eMail etc. merkt (wird ja auch Zeit *g*). Testseite mit Anleitung für Stefan ;-) Hinweisen und allem drum und dran ist unter http://cheatah.net/testcookie.htm zu finden.
Zunächst einmal ist die JavaScript-Routine weitgehend ungetestet. Bei mir funktioniert sie zwar in 100% aller Fälle und erzeugt keinerlei Fehler, ich halte sie auch für korrekt geschrieben, aber man weiß ja nie. Besonders weil ich Cookies noch nicht so richtig[tm] verstehe bitte ich daher alle Experten auf dem Gebiet, sich den Quellcode mal kritisch anzusehen und eventuelle Fehlerquellen aufzudecken. Der Perl-Code ist bisher nur so hingekritzelt, damit die Kommunikation klarer wird; sie wird ohnehin noch überarbeitet, darf aber natürlich auch gerne kontrolliert werden.
Bisher wird der Cookie auch von einer JavaScript-Routine gesetzt, welche dann später entfällt. Die entsprechenden Stellen sind markiert.
Sodele, ich denke, das war's. Fragen, Anmerkungen, Korrekturen bitte per eMail an mich, weil ich dieses Forum nicht regelmäßig lese (NEIN, war'n Scherz!) :-)
Cheatah
-
Hallo Cheatah
ich habe inzwischen eine meiner Meinung nach recht optimierte, aber trotzdem kompatible und "saubere" Routine geschrieben, mit Hilfe derer sich dieses Forum sich via Cookie Name, eMail etc. merkt (wird ja auch Zeit *g*). Testseite mit Anleitung für Stefan ;-)
Hinweisen und allem drum und dran ist unter http://cheatah.net/testcookie.htm zu finden.
OK, Cookie funktioniert bei mir. Aber das allein haut mich noch nicht vom Sessel, denn das man mit Cookies auf einer bestimmten Webseite Formularfelder vorbelegen kann, ist mir klar. Was du mir stattdessen aber noch erklaeren musst, ist, wie der Cookie in die Formularfelder all der vielen statischen HTML-Dateien von der Sorte /selfaktuell/self_forum/25418.html kommt, wenn ich die ganz normal ueber die ebenfalls statische /selfaktuell/self_forum.html aufrufe, und zwar, wie empfohlen, mit der rechten Maustaste in einem neuen Fenster <g>.
viele Gruesse
Stefan Muenz-
hye stefan
Was du mir stattdessen aber noch erklaeren musst, ist, wie der Cookie in die Formularfelder all der vielen statischen HTML-Dateien von der Sorte /selfaktuell/self_forum/25418.html kommt, wenn ich die ganz normal ueber die ebenfalls statische /selfaktuell/self_forum.html aufrufe, und zwar, wie empfohlen, mit der rechten Maustaste in einem neuen Fenster <g>.
in die bestehenden sites kann man die funktion nur mit ein wenig aufwand integrieren.
bei neu genertierten sites ist das cookie dann kein problem mehr --> auf jeder site (zb. diese hier) abfragen ob cookie vorhanden, und falls ja: value="cookie"geht natürlich bei statischen sites nur mit javascript und nicht mit perl.
an cheatah: wichtig!
der pfad für das cookie. wenn ich zb. mein cookie von dieser site bekomme, und der pfad dieser site im cookie-pfad angegeben ist, dann ist das cookie auf den anderen sites nicht verfügbar - aber das weisst du ja wahrscheinlich.ok
cu-
Hi,
an cheatah: wichtig!
der pfad für das cookie. wenn ich zb. mein cookie von dieser site bekomme, und der pfad dieser site im cookie-pfad angegeben ist, dann ist das cookie auf den anderen sites nicht verfügbar - aber das weisst du ja wahrscheinlich.ja, nur ging ich davon aus, daß die Formulare alle im selben Verzeichnis stehen. Wenn nicht, muß man im Perl-Script nur ein "path=/;" anfügen, das dürfte genügen :-)
Aber danke für den Hinweis!
Cheatah
-
-
OK, Cookie funktioniert bei mir. Aber das allein haut mich noch nicht vom Sessel, denn das man mit Cookies auf einer bestimmten Webseite Formularfelder vorbelegen kann, ist mir klar. Was du mir stattdessen aber noch erklaeren musst, ist, wie der Cookie in die Formularfelder all der vielen statischen HTML-Dateien von der Sorte /selfaktuell/self_forum/25418.html kommt, wenn ich die ganz normal ueber die ebenfalls statische /selfaktuell/self_forum.html aufrufe, und zwar, wie empfohlen, mit der rechten Maustaste in einem neuen Fenster <g>.
Die neuen Seiten werden dann ja nicht mehr statisch
sein sondern durch das kleine Script dynamisch :)Mit den alten Seiten siehts natürlich schlecht aus
da sie ja stisch sind und nicht dynamisch aus ner DB
generiert werden.Da müsste man höchstens via Suchen und ersetzen dann
das Script oder den Verweis auf externes Script
einfügen.gruss
Jens -
Hallo,
»» Was du mir stattdessen aber noch erklaeren musst, ist, wie der Cookie in die Formularfelder all der vielen statischen HTML-Dateien von der Sorte /selfaktuell/self_forum/25418.html kommt, wenn ich die ganz normal ueber die ebenfalls statische /selfaktuell/self_forum.html aufrufe, und zwar, wie empfohlen, mit der rechten Maustaste in einem neuen Fenster <g>.
noch ein anderer Ansatz dazu:
- die Funktion "Cookie setzen" kann separat erfolgen (also nicht beim Absenden des Formulars), wer will kann die Funktion aus der self_forum.html heraus aufrufen.
Vorteil soll sein dass die vielen Dateien dadurch entlastet werden. - Falls die Unterdateien wie 25418.html das Cookie der self_forum.html nicht direkt verwenden können: die Cookie Abfrage erfolgt mit der self_forum.html einmal; es wird eine Variable cookie gesetzt. Jeder Link wie 25418.html wird in der self_forum.html mit der Variablen ergänzt "25418.html?"+cookie (wenn das nur über document.write funktioniert könnte es allerdings zuviel Tempo kosten). Beim Aufruf der jeweiligen Datei wird mit dem übergebenen Wert eine neue Variable erzeugt, deren Inhalt in‚s Formularfeld kommen kann. Die genauen Möglichkeiten der Übergabe beim Datei-Aufruf hab‚ ich auf die Schnelle leider nicht parat, aber ohne cgi geht es wohl auch.
Gruesse
Kristof-
Ergänzend zur Übergabe:
ähnlich wie " H. Hatzfeld: Wertübergabe zwischen Dokumenten" kann auch mit "25418.html#"+cookie gearbeitet werden. -
Hallo Kristof,
- Falls die Unterdateien wie 25418.html das Cookie der self_forum.html nicht direkt verwenden können: die Cookie Abfrage erfolgt mit der self_forum.html einmal; es wird eine Variable cookie gesetzt. Jeder Link wie 25418.html wird in der self_forum.html mit der Variablen ergänzt "25418.html?"+cookie (wenn das nur über document.write funktioniert könnte es allerdings zuviel Tempo kosten). Beim Aufruf der jeweiligen Datei wird mit dem übergebenen Wert eine neue Variable erzeugt, deren Inhalt in‚s Formularfeld kommen kann.
OK, das geht mit location.search oder mit location.hash oder window.name. Dann muesste aber jeder Link im Threadbaum ueber JavaScript gesteuert werden. Denn nur JavaScript weiss ja, wie der Inhalt des Dokumenten-Cookies lautet. Folge: alle ein bis zwei Stunden ein Thread des Typs "(ZU DIESEM FORUM) Warum kann ich keine Messages oeffnen?" Antwort: weil du JavaScript ausgeschaltet hast. Na gut, das koennte man vielleicht irgendwie noch hinkriegen und eine Doppelmoppelgeschichte basteln, sodass Leute den Link bei ausgeschaltetem JavaScript normal ausfuehren koennen. Aber die Links zu den Messages wuerden dadurch viel mehr Code enthalten. Folge: die Forumshauptdatei waechst viel schneller als bislang.
Genau das waere dann aber der Effekt, den ich immer so kritisiere an manchen Heldenbastlern. Da soll etwas erleichtert werden, aber dafuer wird geklotzt, was das Zeug haelt, wodurch anderes wieder schwieriger und unhandlicher wird. Und auch wenn ich dafuer schon einmal kritisiert worden bin, ich sage es noch mal: wer hier mit dem MSIE 5 ist, schuettelt ueber diese ganze Diskussion eh nur den Kopf. Anders gesagt: wem ein solches Feature so ungeheuer wichtig ist, kann sich ja auch mal ueberlegen, einen Browser zu verwenden, der das automatisch unterstuetzt.
viele Gruesse
Stefan Muenz-
Anders gesagt: wem ein solches Feature so ungeheuer wichtig ist, kann sich ja auch mal ueberlegen, einen Browser zu verwenden, der das automatisch unterstuetzt.
Tja, "dürfen" heißt das Zauberwort ...
-
Hallo Stefan!
OK, das geht mit location.search oder mit location.hash oder window.name. Dann muesste aber jeder Link im Threadbaum ueber JavaScript gesteuert werden. Denn nur JavaScript weiss ja, wie der Inhalt des Dokumenten-Cookies lautet.
Stimmt nicht. In diesem Falle wuerde ich die Forumshauptdatei durch ein Perl-Script ausgeben lassen, das die search-Parameter direkt in den HTML-Source reinschreibt. Dann braeuchte man nur noch in der aufgerufenen Postingdatei den JS-Code, der den search-Parameter auswertet.
Wie auch immer, das ist doch sowieso nicht noetig. Wir haben nun wirklich genug Code geliefert, der solche Klimmzuege wie Uebergabe ueber den search-Parameter voellig ueberfluessig macht. Ich halte vor allem deswegen nichts von der search-Geschichte, weil es einfach "dirty" ist.
Folge: die Forumshauptdatei waechst viel schneller als bislang.
Wie gesagt, ist nicht noetig. Die Forumshauptdatei ist so ziemlich die einzige, die gar nichts mit Cookies zu tun hat, denn es gibt dort kein Formular, das diese Werte benoetigt. Dafuer wuerde aber jede Postingdatei wachsen. Rechnen wir mal: Cheatah's Anfangs-Posting in diesem Thread ist ca. 10.5 kB gross. Das duerfte so ungefaehr der Durchschnitt fuer eine Postingdatei sein. Dazu kaemen dann nochmal ca. 1-2 kB JS-Code. Das erhoeht die Ladezeit bei einer ISDN-Verbindung um 1/4 Sekunde, bei langsameren Modems um 1/2 Sekunde. Ich halte das fuer durchaus vertretbar.
Genau das waere dann aber der Effekt, den ich immer so kritisiere an manchen Heldenbastlern. Da soll etwas erleichtert werden, aber dafuer wird geklotzt, was das Zeug haelt, wodurch anderes wieder schwieriger und unhandlicher wird.
Stimmt. Aber man muss sich ja nicht den technischen Spielereien um ihrer selbst Willen hingeben und dabei die derzeitige Bedienbarkeit kaputtmachen. Man kann es auch so gestalten, dass Cookies ein Feature sind, und kein Bug.
Calocybe
-
Dafuer wuerde aber jede Postingdatei wachsen. Rechnen wir mal: Cheatah's Anfangs-Posting in diesem Thread ist ca. 10.5 kB gross. Das duerfte so ungefaehr der Durchschnitt fuer eine Postingdatei sein. Dazu kaemen dann nochmal ca. 1-2 kB JS-Code. Das erhoeht die Ladezeit bei einer ISDN-Verbindung um 1/4 Sekunde, bei langsameren Modems um 1/2 Sekunde. Ich halte das fuer durchaus vertretbar.
Und wieviel ist an diesem JavaScript-Code jeweils unterschiedlich?
Wenn wir die Cookies schon "nur" für moderne Browser haben wollen, dann können wir sie auch in eine separate Date cookies.js auslagern. Die wird dann genau einmal statisch erstellt, überall referenziert und vom Browser gecached, und *nichts* wächst ins Uferlose - weder die Ladezeit noch die Größe des Archivs ...
Das bißchen, um das sich der JavaScript-Code ggf. unterscheiden muß, läßt sich an der Aufrufstelle als Parameter übergeben, denke ich ...-
Hallo Michael!
Wenn wir die Cookies schon "nur" für moderne Browser haben wollen, dann können wir sie auch in eine separate Date cookies.js auslagern.
Huch, daran hatte ich ja gar nicht mehr gedacht! Selbstverstaendlich geht das und ist anzuraten! Dadurch muesste Stefan nur drei Zeilen des dateierzeugenden Scripts aendern, naemlich
- Im HEAD das Script linken
- Im BODY-Tag mit OnLoad die Cookie-Auslesroutine aufrufen
- Im FORM-Tag dem Formular einen Namen verpassen und mit OnSubmit die Cookie-Schreibroutine aufrufen
Eventuell koennte er auch das OnSubmit weglassen und dafuer einen Button "Werte speichern" einfuegen. Wurde hier auch schon vorgeschlagen und halte ich fuer eine ganz gute Alternative.
Dieselben Aenderungen muessen dann noch in der self_forum_neu.html noch gemacht werden. Aber zum Glueck gibt's ja Copy&Paste.
Die wird dann genau einmal statisch erstellt, überall referenziert und vom Browser gecached, und *nichts* wächst ins Uferlose - weder die Ladezeit noch die Größe des Archivs ...
Vor langer, langer Zeit hatte in diesem Forum mal jemand gesagt, dass die externen Dateien bei jedem Seitenaufruf vom Browser erneut vom Server abgeholt werden. Ich weiss aber nicht, ob das stimmt. Und wenn, dann betrifft es vermutlich auch nur einen bestimmten Browser.
Das bißchen, um das sich der JavaScript-Code ggf. unterscheiden muß, läßt sich an der Aufrufstelle als Parameter übergeben, denke ich ...
Nun, der Code ist fuer jede Datei voellig gleich! Da brauchen wir nix Parameter oder sowas.
Calocybe
-
-
- die Funktion "Cookie setzen" kann separat erfolgen (also nicht beim Absenden des Formulars), wer will kann die Funktion aus der self_forum.html heraus aufrufen.
-
Hi Stefan,
OK, Cookie funktioniert bei mir. Aber das allein haut mich noch nicht vom Sessel, denn das man mit Cookies auf einer bestimmten Webseite Formularfelder vorbelegen kann, ist mir klar. Was du mir stattdessen aber noch erklaeren musst, ist, wie der Cookie in die Formularfelder all der vielen statischen HTML-Dateien von der Sorte /selfaktuell/self_forum/25418.html kommt, wenn ich die ganz normal ueber die ebenfalls statische /selfaktuell/self_forum.html aufrufe, und zwar, wie empfohlen, mit der rechten Maustaste in einem neuen Fenster <g>.
wie der Code in die _bereits existierenden_ Seiten kommt, mußt Du selbst sehen *g* aber ich persönlich würde einfach sagen: Nur in neue Seiten, die alten Formulare verschwinden in ein, zwei Wochen von selbst.
Wenn der Code aber in einer Seite steht, erledigt sich alles von alleine. Er steht hinter dem Formular, also existiert dieses bereits, und beim Aufbau der Seite werden die Felder ganz einfach verändert. Egal, ob mit rechter Maustaste geöffnet oder nicht ;-)
Cheatah
-
-
Hallo Cheatah,
bei mir funktioniert der Cookie korrekt, ich nutze W95 und den IE5.
Ein Problem habe ich allerdings damit: Ich benutze ZWEI E-Mail-Adressen, meine private und die aus der Firma. Diese Möglichkeit hätte ich dann nicht mehr.
Nicht richtig wichtig, aber lästig...CU,
Carsti
-
Hi,
bei mir funktioniert der Cookie korrekt, ich nutze W95 und den IE5.
danke :-)
Ein Problem habe ich allerdings damit: Ich benutze ZWEI E-Mail-Adressen, meine private und die aus der Firma. Diese Möglichkeit hätte ich dann nicht mehr.
Nicht richtig wichtig, aber lästig...Doch, kannst Du immer noch:
a) bleiben Dir die Felder schließlich erhalten, Du kannst also nachträglich ändern,
b) hast Du auf jedem Rechner eine eigene Cookie-Datei, also auch eine eigene Einstellung. Wenn Du also bei der Arbeit die eine und privat die andere Adresse eingeben willst, geschieht das schon automatisch :-)Cheatah
-
-
Moin Cheatah,
wenn das mit den Cookies schon unbedingt sein soll:
Bitte lass doch wenigstens das IMAGE-Feld weg. Ich halte diese Form der Schleichwerbung sowieso für überfluessig -
<g> und diejenigen, die uns mit häufig wechselnden Grafiken (HWG) beglücken, müssten ständig etwas ändern und hätten nichts mehr von der Arbeitserleichterung </g>Swen
-
Hi,
wenn das mit den Cookies schon unbedingt sein soll:
Bitte lass doch wenigstens das IMAGE-Feld weg. Ich halte diese Form der Schleichwerbung sowieso für überfluessig -
»» <g> und diejenigen, die uns mit häufig wechselnden Grafiken (HWG) beglücken, müssten ständig etwas ändern und hätten nichts mehr von der Arbeitserleichterung </g>
das überlasse ich voll und ganz Stefan, die Änderungen dazu sind minimal (alles mit "img" weglassen, naja, eines der beiden "http://" in der Back/Forward-Prüfung müßte weggelassen werden). Ich persönlich denke aber, daß durch das vorbelegte Grafik-Feld kein Schaden entstehen würde: Diejenigen die es setzen wollen, tun es ohnehin. Eine Vorbelegung durch Cookie spart ihnen nur Zeit. Vielmehr sollte sich jeder überlegen, ob er überhaupt seine Grafik anhängen sollte - die meisten sind aber IMHO nicht besonders störend (gell, PAF? *g*)
Einzig könnte ich mir vorstellen, daß jemand im einen Posting schreibt "...ich habe dazu eine Grafik, die füge ich mal an..." und es im nächsten Posting vergißt - aber mal ehrlich: Wie oft passiert das? Solche Bilder werden gewöhnlich über Stefan's Pseudo-HTML eingefügt (genau wie Links); unten findet man i.d.R. nur die persönlichen Bilder, die jemand jedes Mal einfügt.
Wie gesagt ist das aber Stefans Entscheidung. Ich will nur einen funktionierenden Code liefern, den Stefan benutzen kann _wenn er will_. Nicht mehr. Naja, vielleicht will ich ihn auch ein wenig dazu animieren, den Code auch einzubauen... ;-)
Cheatah
-
-
Hi Cheatah!
Zunächst einmal ist die JavaScript-Routine weitgehend ungetestet. Bei mir funktioniert sie zwar in 100% aller Fälle und erzeugt keinerlei Fehler, ich halte sie auch für korrekt geschrieben, aber man weiß ja nie. Besonders weil ich Cookies noch nicht so richtig[tm] verstehe bitte ich daher alle Experten auf dem Gebiet, sich den Quellcode mal kritisch anzusehen und eventuelle Fehlerquellen aufzudecken. Der Perl-Code ist bisher nur so hingekritzelt, damit die Kommunikation klarer wird; sie wird ohnehin noch überarbeitet, darf aber natürlich auch gerne kontrolliert werden.
Bisher wird der Cookie auch von einer JavaScript-Routine gesetzt, welche dann später entfällt. Die entsprechenden Stellen sind markiert.
Mmh, warum willst Du unbedingt Perl einsetzen? JS funktioniert doch gut, und die paar Uralt-Browser, die es nicht koennen, na die haben eben keine Cookies. Vor allem wuerde das ein dynamisches Erzeugen der derzeit statischen Posting-Dateien vermeiden. Einfach das Forums-Script beim Erzeugen der Dateien den JS-Code mit reinschreiben lassen, und fertig. Wenn Du eine hoehere JS-Version voraussetzt, dann musst Du auch nicht solche Klimmzuege machen, um den Cookie wieder auszulesen (in JS gibt's naemlich auch split()).
Ich hab mir Deinen Code nicht intensiv anbgeschaut, aufgefallen ist mir nur, dass Du den PATH nicht setzt, fuer den der Cookie gueltig ist (vgl. Codevorschlaege von Jens und mir in <../../sfarchiv/1999_3/t05075.htm>). Dadurch kann, wie Stefan damals schon befuerchtet hat, eine Postingdatei nicht auf den Cookie einer anderen zugreifen.
Ich persoenlich setze den Code lieber in eine Funktion, die ich dann OnLoad aufrufen lasse, statt den Code hinter das Formular zu setzen und sofort losrennen zu lassen, aber das ist wohl Geschmackssache.
Nun gut, mehr faellt mir auf den ersten Blick nicht auf.
Calocybe-
Hi,
Mmh, warum willst Du unbedingt Perl einsetzen? JS funktioniert doch gut, und die paar Uralt-Browser, die es nicht koennen, na die haben eben keine Cookies. Vor allem wuerde das ein dynamisches Erzeugen der derzeit statischen Posting-Dateien vermeiden. Einfach das Forums-Script beim Erzeugen der Dateien den JS-Code mit reinschreiben lassen, und fertig.
das hast Du offenbar falsch verstanden. Wenn Du einen Artikel schreibst, erhälst Du eine Bestätigungsseite, mit der zusammen (bei Bedarf) ein Set-Cookie-Header geschickt wird und den Cookie erstellt. Würde ich das mit JavaScript lösen, würde _das_ Klimmzüge erfordern. Die Seiten selbst bleiben statisch, da der (statische) JavaScript-Code den Cookie ins Formular umsetzt.
Wenn Du eine hoehere JS-Version voraussetzt, dann musst Du auch nicht solche Klimmzuege machen, um den Cookie wieder auszulesen (in JS gibt's naemlich auch split()).
Tja, aber besser ist es doch, JS 1.0 kompatibel zu bleiben ;-)
Ich hab mir Deinen Code nicht intensiv anbgeschaut, aufgefallen ist mir nur, dass Du den PATH nicht setzt, fuer den der Cookie gueltig ist (vgl. Codevorschlaege von Jens und mir in <../../sfarchiv/1999_3/t05075.htm>). Dadurch kann, wie Stefan damals schon befuerchtet hat, eine Postingdatei nicht auf den Cookie einer anderen zugreifen.
Alle Formulare dürften im Verzeichnis /self-forum liegen, deswegen habe ich darauf verzichtet; aber danke für den Hinweis. Die Änderung wäre minimal (nur ein paar Bytes im Perl-Code), erschien mir aber überflüssig.
Ich persoenlich setze den Code lieber in eine Funktion, die ich dann OnLoad aufrufen lasse, statt den Code hinter das Formular zu setzen und sofort losrennen zu lassen, aber das ist wohl Geschmackssache.
Tja, ohne onLoad wird der Code schneller angesprochen. Stell Dir nur mal vor, kurz hinter dem Formular wäre ein Datenstau, oder eine bestimmte Grafik wird einfach nicht angesprochen; da würde man ewig warten. So hat man eine vernachlässigbare Verzögerung, und man spart sich einen in exotischen Browsern evtl. problematischen Event-Handler.
Nun gut, mehr faellt mir auf den ersten Blick nicht auf.
Danke :-)
Cheatah
-