nicht angemeldet
neuer HTML Code senden
Hi all
Ich hab jetzt schon mehrmals von Methoden gehört, wie man neuer HTML-Code nachträglich vom Server an den Browser sendet.
Ich möchte das (wie im Thema erwähnt) mit Perl erledigen.
Doch wie genau funktioniert das?
Danke vielmals an alle Forummer!
Bye
Barna
-
neuer HTML-Code nachträglich vom Server an den Browser sendet.
Was verstehst Du unter "neuem" Code?
Falls Du generierten Code meinst: alles was im Rahmen eines cgi nach stdout geschrieben wird, geht per http raus. Siehe die entsprechenden Kapitel in selfHTML und ggf. das CGI Modul aus dem CPAN (comprehensive Perl Archive Network)
-
Hi K@rl
Was verstehst Du unter "neuem" Code?
Wenn ich z.B. eine Liste habe, die alle Paar sekunden um eine Linie erweitert wird. Anstatt immer wieder reload zu machen (braucht nach ein paar linien sehr viel downloadzeit) einfach neuer Code vom server dazuschreiben zu lassen, ohne dass die Seite neu geladen werden muss.
Geht das überhaupt???
Sonst muss ich es halt doch mit Javascript in ein Frame mit document.print dazuschreiben...-
Wenn ich z.B. eine Liste habe, die alle Paar sekunden um eine Linie erweitert wird. Anstatt immer wieder reload zu machen (braucht nach ein paar linien sehr viel downloadzeit) einfach neuer Code vom server dazuschreiben zu lassen, ohne dass die Seite neu geladen werden muss.
Geht das überhaupt???Server-Push .. hab' ich mich noch nicht mit beschäftigt. Ist aber (Irrtum vorbehalten) kein Perl / cgi Thema. Denn nach meinem Weltbild wird mit dem HTTP Protokoll immer ein °Dokument° übertragen. Eine kleinere Einheit gibt es nicht (also nicht: Zeilen eines Dokuments).
Wie wäre es mit einem Frame mit einem (Perl-generierten) Dokument, wo immer die letzten 3 - 10 aktuellen Meldungen drin sind und ein Link auf alle Meldungen? ... falls Du so eine Art News Ticker implementieren willst.
Ansonsten bleibt noch die Alternative Java Applet. Da kannst Du das Applet sich mit dem Server "unterhalten" lassen.
-
Hi
Danke für die schnelle Antwort.
Hmm, dann kann ich es ja gleich so lassen wie es jetzt ist:
Momentan hab ich in einem 1 pixel hohen frame ein auto reload von 3 sekunden. Darin werden immer die aktuellsten zeilen geladen, und per javascript ins haupt frame geschrieben. Das geht auch problemlos.Bye
-
Momentan hab ich in einem 1 pixel hohen frame ein uto reload von 3 sekunden. Darin werden immer die aktuellsten zeilen geladen, und per javascript ins haupt frame geschrieben. Das geht auch problemlos.
Klingt nach einer schönen Lösung - wo ist die denn im Web zu bewundern?
-
Hi
Klingt nach einer schönen Lösung - wo ist die denn im Web zu bewundern?
Leider noch nirgends :-(
Als ich es mal online wegen der geschwinidigkeit testen wollte, kam der webspace provider und sagte, das script werde nicht zugelassen, weil es deren Server zu fest belastet :-(
Ich habe mich schon mal bei free.prohosting.com angemeldet, aber dort will das script einfach nicht funktionieren.
Da das script sonst noch viel javascript verteilt, geht es leider nur mit netscape :-(also noch viel zu viele :-('s um es zu veröffentlichen :-)
Bye
-
ANHANG:
Als ich es mal online wegen der geschwinidigkeit testen wollte, kam der
webspace provider und sagte, das script werde nicht zugelassen, weil es deren
Server zu fest belastet :-(Deshalb such ich ne alternative
-
-
-
-
Moin K@rl,
Server-Push .. hab' ich mich noch nicht mit beschäftigt. Ist aber (Irrtum vorbehalten) kein Perl / cgi Thema. Denn nach meinem Weltbild wird mit dem HTTP Protokoll immer ein °Dokument° übertragen. Eine kleinere Einheit gibt es nicht (also nicht: Zeilen eines Dokuments).
stimmt nach meiner Erfahrung so nicht. Es gibt etliche Server, die "unbuffered cgi" zulassen, d.h. den generierten html-Code nicht zwischenspeichern sondern gleich stückweise zurücksenden. Ein prominentes Beispiel ist z.B. die Meta-Suchmaschine auf http://meta.rrzn.uni-hannover.de, die alle 10 Sek. anzeigt, welche Suchdienste noch abgefragt werden.
Server, bei denen dies geht, sind auf jeden Fall u.a. der Apache (mit sog. nph-Skripts, hab mich selber noch nicht damit beschäftigt), und auch PWS oder IIS von Microsoft scheint cgi-Ausgaben ohne Zwischenspeicherung weiterzuleiten. Mit Xitami geht es dagegen z.B. nicht, bei anderen Servern hab ich's noch nicht probiert.
Was z.B. funktioniert, ist, ein Formular generieren zu lassen und dann sukzessive vom cgi-Skript aus Javascript-Blöcke der Form
<script language="JavaScript">
<!--
document.formName.iter.value="Iteration Nr. 007";
document.formName.error.value="Fehlerquadrat = 4711.0";
document.formName.par1.value="parameter1 = 1.6180339887";
// .. usw.
//-->
</script>generieren zu lassen, um z.B. einen längeren Iterationsvorgang überwachen zu können.
Wie ja auch schon im Forum erwähnt, sind daher die Tags <html> bzw. </html> usw. nicht zwingend erforderlich, um im Browser ein html-Dokument darzustellen.Bis dannundwann...
Andreas
-
Hoi Andreas,
danke für die Berichtigung meines Weltbildes.
nph (= "non parsed headers", oder?) .. ist mir zwar schon mal über den Weg gelaufen, aber habe mich noch nicht genauer damit beschäftigt. Bist Du sicher, daß man damit an bereits im Browser befindliche Dokumente weitere Teile anhängen kann?
Unbuffered Transfer zum Browser - o.k., aber alles beginnt doch mit einem HTTP request und endet mit der Übertragung des Dokuments. Was man höchstens machen könnte, wäre den Transfer sowohl in Perl ($ = 1) und im Apache auf ungepuffert setzen, den HTTP Header senden und dann irgend sowas wie:
print "Content-Type: text/html\n\n";
print "<html><body>";...
while (1) {
# $ausgabe = .. ermittle die Ausgabe ..;
print "<hr>", $Ausgabe, "\n";
sleep 10
}Aber macht das wirklich Sinn? Ist das praktikabel?
Oder bin ich schon wieder auf'm Bananendampfer?Huhu Barna! -> ist Andreas' Posting die Antwort auf Deine Frage?
-
Hiho K@rl,
print "Content-Type: text/html\n\n";
print "<html><body>";...
while (1) {
# $ausgabe = .. ermittle die Ausgabe ..;
print "<hr>", $Ausgabe, "\n";
sleep 10
}Aber macht das wirklich Sinn? Ist das praktikabel?
Oder bin ich schon wieder auf'm Bananendampfer?ich glaube, die Sache macht vor allem dann Sinn, wenn ein cgi-Skript zur Ausführung sehr lange braucht, wenn z.B. irgendwelche komplizierteren Berechnungen angestellt werden sollen. Schon alleine, damit der Webserver nicht irgendwann mangels Lebenszeichen die Verbindung kappt (d.h. den cgi-Prozeß "killt"), wären Zwischenausgaben sinnvoll. Ist natürlich auch psychologisch netter, wenn der User weiß, daß er noch 20 Minuten warten soll, anstatt ihm einfach 20 min lang ein bewegungsloses Bild eines Browsers zu präsentieren - das hält dann garantiert keiner durch <g>.
Bis dannundwann....
Andreas
-
Ist natürlich auch psychologisch netter, wenn der User weiß, daß er noch 20 Minuten warten soll, anstatt ihm einfach 20 min lang ein bewegungsloses Bild eines Browsers zu präsentieren - das hält dann garantiert keiner durch <g>.
Ich habe die letzten Tage damit verbracht, so etwas Ähnliches zu entwickeln.
Ganz kurz: Der Anwender startet via CGI einen "Auftrag", welcher auf dem Server-Rechner an einen Warteschlagenverwalter übergeben wird. Dieser synchronisiert dann die Aufträge und startet einen nach dem anderen.
Der Anwender will im Browser aber mitbekommen, wann es wirklich losgeht und was auf dem Server so passiert.Ich habe als Reaktion auf das abgeschickte Formular via CGI ein Frameset aus zwei Frames generiert, welche jeweils wieder CGI-Calls enthalten.
Im größeren Frame erscheint eine Art Auftragsbeschreibung; via HTTP-Refresh aktiviert dieses CGI sich selbst nochmal mit geänderten Parametern, was einen Wartevorgang von max. 30 Sekunden auslöst, an dessen Ende entweder ein Timeout oder ein HTML-Dokument mit Hyperlinks auf die auf dem Server generierten Dateien steht. (Und
ein button "weiter warten", der den ersten der beiden CGI-Calls nochmal ausführt.)Im kleineren Frame erscheint ein HTML-Dokument, welches sich via HTTP-Refresh ständig selbst neu läuft (Frequenz wird in Abhängigkeit der Verarbeitungsphase dynamisch berechnet; es ist eine Intranet-Anwendung, ich habe also keine Bandbreitenprobleme; das Dokument ist auch nur 350 bytes groß). Dieses Skript weiß via CGI-Parameter die Namen aller temporären Dateien des Prozesses, kann also in einer Art "Statusleiste" (triviale HTML-Tabelle) jeweils anzeigen, in welcher Verarbeitungsphase der Auftrag ist, wie lange die ganze Sache schon läuft (Startzeit wird via CGI übergeben) und wie groß die aktuelle Datei derzeit ist.
Fazit: "Der Browser lebt." Und alles ohne Server-Push.
Endlich die Klicki-Bunti-Lösung, die die Kunden schon immer haben wollten ... Aber fragt nicht, wie lang die CGI-Parameterlisten sind. :-(
-
-
-
-
-
-
-
Hallo Barna
Ich möchte das (wie im Thema erwähnt) mit Perl erledigen.
Doch wie genau funktioniert das?Beschaeftige dich mal mit Dynamic HTML!
<../../tf.htm>viele Gruesse
Stefan Muenz