Forum

Öffentliche Foren

FORUM: Spiele & Computer THEMA: [PHP] Chat

AUTOR	BEITRAG
Morph RANG Deckschrubber	#1 - 26.08 18:46 Hi ho, kA wer es kennt, seh es selber selten. Aber ... es gibt einen Chat halt in PHP geschrieben, das Senden ist ja kein Ding, die Ausgabe auch nicht. Was ich mich allerdings Frage ist: Wie bekommen die das hin, dass wenn ich auf Abschicken klicken tu, dass sofort das Content Fenster sich neulädt und dann das geschriebene schon brav dort steht. Habe im Quelltext rumgewühlt aber nix gefunden, jemand ne Idee?
horst RANG Prophet of Clanintern	#2 - 26.08 20:45 Die werden vermutlich beim onClick Events des Buttons Javascript Funktionalität rufen, um a) Den Text in das Inhaltsfenster zu schreiben (document.write) b) Die Seite im Inhaltsfenster neu zu laden (window.location.href) Dass sie die Chatfensterseite "endlos" streamen kann ich mir nicht vorstellen. Ich denke viel mehr, dass sie dann noch Javascript in der Seite haben, die sie alle x Sekunden neu laden lässt. Finito. So dauert es zwar immer bis zum Trigger, bis der neue Inhalt da steht, sollte aber funktionieren. Ich kann mir irgendwie nicht vorstellen, dass sie den Inhalt durchgängig rausstreamen und so "endlos" content produzieren.
al!ve - Vorbereitung aufs Urlaubssemester RANG Master of Clanintern	#3 - 26.08 21:14 Hier würde sich AJAX anbieten. Im Googlemail-HTML-Source steht bestimmt n bissl was, immerhin erfährt das Browserfenster auch ohne Reload immer recht zügig, wenn ich ne neue Mail bekommen hab. Gut zu beobachten wenn ich mir von einem externen Konto, bei GMX oder sowas, ne Mail an meine Googlemail-Adresse schicke. Man kann den Chat-Content ja auch in Packete gliedern. Der Chat-Server speichert alle Zeilen etwa 60 Sekunden lang, bzw ein "Senden" erzeugt nen Eintrag in der Datenbank und jeder Seitenaufruf löscht alle, die älter als 60 Sekunden sind. Bei jeder Anfrage schick ich ein "gib mir alle, die seit Zeitpunkt XYZ erzeugt wurden" und als Antwort erhalte ich ne Liste aller Einträge mit zusätzlicher Zeitansage "beim nächsten Piep ist es 23 Uhr, 11 Minuten und 58 Sekunden Piep". Client in JS realisiert, Server in PHP. Das Request-Event kann ganz einfach sein, muss nur n POST sein mit ner entsprechenden Session, die Antwort wahlweise XML, serialized Array oder formatiertes HTML. Die ersten beiden Möglichkeiten hätten den Vorteil, dass der Client nicht zwangsweise ein HTML-Browser sein muss sondern nachträglich auch anders implementiert werden kann.
Morph RANG Deckschrubber	#4 - 27.08 14:34 Gut, ich kenn das jetzt von ilove (Ja ... ich bin so ein Kaputter) da haste dann oben immer so ein schickes kleines Fenster, welches im Header erscheint, und dann z.b. signalisiert das jemand gerade das krasse Profil am anschauen ist. Aber demnach muesste Ajax ja ne Dauerverbindung haben ... . Habe auch schon rumgesucht, aber nix der gleichen gefunden. Alles hat sich auf abgeschlossene Requests bezogen.
deluxe photoenthusiast RANG Master of Clanintern	#5 - 27.08 16:07 AJAX is ja auch nur eine "Methode" einen http-Request abzusetzen. Das is im Grunde die selbe Leier wie mit dem Refresh nur, dass es im Hintergrund läuft.
Morph RANG Deckschrubber	#6 - 27.08 17:23 Ach so, schade. Dachte Ajax könnte ne Dauerverbindung aufrecht erhalten.
aphex // benny status: patchslut RANG Godlike	#7 - 27.08 19:07 kannste auch...nennt sich dann aber comet. wäre ich aber sehr vorsichtig, dann zwingt den http server ohne probleme in die knie wenn man nicht aufpasst.
al!ve - Vorbereitung aufs Urlaubssemester RANG Master of Clanintern	#8 - 27.08 19:14 Nur wie grade von mir beschrieben, muss nicht zwingend die ganze Seite neu geladen werden, es reicht, wenn der Browser den Server nach "was hat sich seit meinem letzten Refresh getan" fragt und dafür ne XML-Antwort bekommt, ohne den restlichen HTML-Body und sämtliche Bilder neu mitladen zu müssen. Für den Benutzer wirkt das dann deutlich flüssiger, dass man nur einmal alle zwei Sekunden refresht und zusätzlich, wenn man ne Nachricht abgesetzt hat, kriegt der Benutzer so gar nicht mit.
Morph RANG Deckschrubber	#9 - 28.08 20:38 Ich glaub das ist auch die Idee ... . Danke schön - wünsch euch noch nen schönen Abend.
al!ve - Vorbereitung aufs Urlaubssemester RANG Master of Clanintern	#10 - 29.08 02:54 Nachteil an der Sache ist halt, dass das nur mit aktiviertem JavaScript funktioniert. Wenn ich aber von nem Client spreche, der nicht zwangsweise HTML-Browser sein muss, dann kann das ja trotzdem einer sein, der innerhalb eines HTML-Browsers abläuft. Wenn die Kommunikation zwischen "Client" (Browser) und "Server" (PHP-Script) über XML oder n serialized Array läuft, kann man sich auch nen Java-Applet-Client schreiben, oder einen in Flash mit ActionScript, ohne die Serveranwendung (PHP-Script) anpassen zu müssen oder sogar nochmal schreiben. Somit wäre man wiederum von JavaScript unabhängig und könnte mit nur geringfügig mehr Aufwand (eben der Aufwand eines zusäztlichen Clients) dem Benutzer die Wahl lassen: - Will ich den Komfort-JS-Client? - Will ich den noch komfortableren Flash-Client? - Will ich den optisch nicht ganz so ansprechenden Java-Applet-Client? - Will ich garnix von alledem sondern nur pures HTML, dann hab ich ne Seite, die sich alle drei Sekunden mit Meta-Refresh neu aufbaut. Unschön, aber funktioniert auch ganz ohne "Spielereien". Was ich in #3 geschrieben hab ist natürlich nur bedingt sinnvoll. Der Client muss den Server natürlich nicht unbedingt fragen "was ist seit Zeitpunkt xyz passiert", sondern er darf fragen "was ist seit meiner letzten Anfrage passiert". Der Server darf sich selbst merken, wann die letzte Anfrage war und was seither passiert ist. Wenn der Client bei der Anfrage jedoch die Zeit mitschickt, wann die letzte Abfrage war, so kann auch mal ein Auto-Refresh "verloren" gehen (Client stellt Anfrage, Server schickt Antwort aber Antwort kommt nie beim Client an), der Client könnte den Verlust bemerken und bei der nächsten Anfrage einfach nicht die Zeit der letzten, fehlerhaften Anfrage sondern der vorletzten, korrekten Anfrage mitschicken. Denkbar ist beides, evtl auch eine Kombination bzw die Wahlfreiheit. Kann JavaScript eigentlich beliebige Socketverbindungen aufbauen oder "nur" eine weitere XMLHttpRequest-Instanz erzeugen, um zu kommunizieren? Für AJaX reicht natürlich letzteres, wenn man allerdings ne normale Socketverbindung auf nen beliebigen Port aufbauen könnte, könnte man ne JavaScript-Anwendung schreiben, die direkt zu einem IRC-Server verbindet. Spart man sich den Server dahinter, wenn man einfach auf einen der vielen Standardserver verbindet, die es so im Bereich IRC so gibt.

ZURÜCK