Bisherige "print-Ausgabe" löschen

[Peter]

Hallo,
wenn ich in Perl eine HTML-Seite generiere, kann ich dann mittendrin (beim Erkennen eines Fehlers) die bisherige Ausgabe löschen, um dann eine Fehlerseite auszugeben?
Gruß
Peter

[Beat]

wenn ich in Perl eine HTML-Seite generiere, kann ich dann mittendrin (beim Erkennen eines Fehlers) die bisherige Ausgabe löschen, um dann eine Fehlerseite auszugeben?

Nachdem du
  print Content-type: text/html \n\n
ausgegeben hast, gibt es keine Fehlerseite (Statuscode) mehr.
alles, was über
  print
oder
  fprint
an die Ausgabe gesendet wird, kann nicht wieder zurückgenommen werden.
Jedoch ist folgendes möglich:
  print "$Var ist ", ($var == 1 ? " " : " nicht "), 1;

Fehler gehören in der Regel nicht an den Browser geschickt, sondern in ein dem Admin leicht erreichbares File geschrieben.

mfg Beat

[Peter]

Nachdem du
  print Content-type: text/html \n\n
ausgegeben hast, gibt es keine Fehlerseite (Statuscode) mehr.

Es soll kein Statuscode ausgegeben werden, sondern nur eine sinnvolle Seite an den Anwender, denn   s.u.

alles, was über
  print
oder
  fprint
an die Ausgabe gesendet wird, kann nicht wieder zurückgenommen werden.
Jedoch ist folgendes möglich:
  print "$Var ist ", ($var == 1 ? " " : " nicht "), 1;

Fehler gehören in der Regel nicht an den Browser geschickt, sondern in ein dem Admin leicht erreichbares File geschrieben.

Das wird auch gemacht, aber ich möchte dem Anwender keine halbfertige Seite senden.

Gruß
Peter

[Beat]

Das wird auch gemacht, aber ich möchte dem Anwender keine halbfertige Seite senden.

Wo hast du denn den konzeptionellen Bock drin?
Ich gehe irgendwie voraus, dass du die Voraussetzungen deines Tuns unzureichend prüfst.

mfg Beat

[Peter]

Hallo

Wo hast du denn den konzeptionellen Bock drin?

Es ist doch naheliegend - zumindest kenne ich das aus Nicht-Internet-Anwendungen, dass mit einer "reset-Angabe" das bisherige noch nicht per "commit" abgeschlossene rückgängig gemacht werden kann.
Und wenn ich eine Seite aufbereite und dafür z.B. Dateien lese, die normalerweise vorhanden sind, kann es doch sein, dass dies einmal aus irgendwelchen Gründen nicht der Fall ist.
Alle Dateien, die möglicherweise für die konkrete Ausgabe in Frage kommen möchte ich nicht vorab lesen.

Gruß
Peter

[Beat]

Alle Dateien, die möglicherweise für die konkrete Ausgabe in Frage kommen möchte ich nicht vorab lesen.

Brauchst du auch nicht. Ein Filetest erspart dir das.

mfg Beat

[Peter]

Brauchst du auch nicht. Ein Filetest erspart dir das.

Es kann ja auch am Inhalt liegen!

[steckl]

Hi,

Und wenn ich eine Seite aufbereite und dafür z.B. Dateien lese, die normalerweise vorhanden sind, kann es doch sein, dass dies einmal aus irgendwelchen Gründen nicht der Fall ist.

Du musst mit der Ausgabe so lange warten, bis du weißt ob die Dateien vorhanden sind.
Du kannst ja die auszugebenden Daten inzwischen so lange in einer Variablen speichern, falls dies nötig ist.

Alle Dateien, die möglicherweise für die konkrete Ausgabe in Frage kommen möchte ich nicht vorab lesen.

Es wird dir wohl nichts anderes übrig bleiben. Aber was heißt möglicherweise? Du solltest doch wissen, welche Dateien es konkret sind.

mfG,
steckl

[Matti Maekitalo]

Tach auch.

zuerst einmal: habe lange kein Perl mehr programmiert, aber ich skizziere hier eine Idee, von der ich der Meinung bin, dass sie funktionieren könnte.

wenn ich in Perl eine HTML-Seite generiere, kann ich dann mittendrin (beim Erkennen eines Fehlers) die bisherige Ausgabe löschen, um dann eine Fehlerseite auszugeben?

Wie wäre es, wenn du deine Ausgaben per select() umleitest, um dann später, wenn der Erfolg feststeht, dann alles aus dem gewählten IO-Handler rausholst?

Bis die Tage,
Matti

[Struppi]

wenn ich in Perl eine HTML-Seite generiere, kann ich dann mittendrin (beim Erkennen eines Fehlers) die bisherige Ausgabe löschen, um dann eine Fehlerseite auszugeben?

Nein, aber dein Vorgehen ist auch nicht sinnvoll. Besser ist es, während dem Ablauf des Skriptes, die Ausgabe zu sammeln und dann an einer Stelle alles auf einmal auszugeben, dann tauchen solche Fragestellungen gar nicht auf.

Struppi.

[Siechfred]

wenn ich in Perl eine HTML-Seite generiere, kann ich dann mittendrin (beim Erkennen eines Fehlers) die bisherige Ausgabe löschen, um dann eine Fehlerseite auszugeben?

Dein Gesamtkonzept ist bisher unbekannt, weshalb man nur raten kann. Grundsätzlich solltest Du wissen, dass alle Ausgaben auf STDOUT (print usw.) vom Server "gesammelt" und erst zum Schluss zu einer HTTP-Response zusammengebaut und ausgeliefert werden, es sei denn Du hättest eine NPH-Anwendung. Einmal ausgegeben, ist aber grundsätzlich keine Korrektur mehr möglich.

Du könntest Dein HTML in einer Variable "sammeln" und am Ende des Scripts ausgeben. Während der Laufzeit kannst Du dann alles mögliche machen, z.B. das bisher gesammelte HTML komplett löschen.

Siechfred

[Peter]

Hallo

Dein Gesamtkonzept ist bisher unbekannt, weshalb man nur raten kann.

Was war an meiner Frage unklar?

  
....  
print qq~  
   <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">\n~;  
print "<html>\n<head>\n";  
print "<title> .....\n";  
  
....  
  
if ($x eq "1") {print "blablabla"}  
if (GAU ist passiert)         # bisheriges löschen und neu anfangen  
else                          # normal weitermachen  
....  
  print"</html>";  

Grundsätzlich solltest Du wissen, dass alle Ausgaben auf STDOUT (print usw.) vom Server "gesammelt" und erst zum Schluss zu einer HTTP-Response zusammengebaut und ausgeliefert werden, es sei denn Du hättest eine NPH-Anwendung.

Gerade deshalb meinte ich ja, man könnte das Gesammelte und noch  n i c h t Ausgelieferte löschen.

Einmal ausgegeben, ist aber grundsätzlich keine Korrektur mehr möglich.

Das ist mir klar.

Du könntest Dein HTML in einer Variable "sammeln" und am Ende des Scripts ausgeben. Während der Laufzeit kannst Du dann alles mögliche machen, z.B. das bisher gesammelte HTML komplett löschen.

Das wäre nicht nötig, wenn obiges von dir geschriebene funktioniert,
nämlich das vom Server gesammelte aber noch nicht ausgegebene wird über eine Anweisung an den Server gelöscht. Denn warum soll ich sammeln, wenn es der Server für mich tut. Ich vergleiche es mit dem Schreiben in eine Datenbank, wo ich auch zurücksetzen kann bis zum commit.

Peter

[Struppi]

....
print qq~
   <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">\n~;
print "<html>\n<head>\n";
print "<title> .....\n";

....

if ($x eq "1") {print "blablabla"}
if (GAU ist passiert)         # bisheriges löschen und neu anfangen
else                          # normal weitermachen
....
  print"</html>";

  
und genau dieses serielle ausgeben von HTML Code ist ein sehr schlechtes Konzept. u.a. eben weil du dann nichts mehr Rückgängig machen kannst. Wie schon erwähnt, möchtest du entweder die Ausgabe sammeln oder eines der Template Module verwenden, alles andere ist Murks.  
  

> > Grundsätzlich solltest Du wissen, dass alle Ausgaben auf STDOUT (print usw.) vom Server "gesammelt" und erst zum Schluss zu einer HTTP-Response zusammengebaut und ausgeliefert werden, es sei denn Du hättest eine NPH-Anwendung.  
> Gerade deshalb meinte ich ja, man könnte das Gesammelte und noch  n i c h t Ausgelieferte löschen.  
  
Du kannst das was du auf STDOUT ausgegeben hast nicht mehr löschen.  
  

> > Einmal ausgegeben, ist aber grundsätzlich keine Korrektur mehr möglich.  
> Das ist mir klar.  
  
Naja, dann ändere das doch.  
  

> Das wäre nicht nötig, wenn obiges von dir geschriebene funktioniert,  
> nämlich das vom Server gesammelte aber noch nicht ausgegebene wird über eine Anweisung an den Server gelöscht. Denn warum soll ich sammeln, wenn es der Server für mich tut. Ich vergleiche es mit dem Schreiben in eine Datenbank, wo ich auch zurücksetzen kann bis zum commit.  
  
Das kannst du damit nicht vergleichen, weil es nicht so ist. Die Ausgabe wird zwar u.U. gepuffert (gesammelt), aber nicht zum Zwecke der nachträglichen Bearbeitung, sondern nur damit die Ausgabe schneller ist.  
  
Struppi.

[Peter]

Hi,

und genau dieses serielle ausgeben von HTML Code ist ein sehr schlechtes Konzept. u.a. eben weil du dann nichts mehr Rückgängig machen kannst. Wie schon erwähnt, möchtest du entweder die Ausgabe sammeln oder eines der Template Module verwenden, alles andere ist Murks.

Dann besteht das Internet zu 95% aus Murks!
In fast allen Perl-Beispielen - auch in SELFHTML - wird so vorgegangen!

Das kannst du damit nicht vergleichen, weil es nicht so ist. Die Ausgabe wird zwar u.U. gepuffert (gesammelt), aber nicht zum Zwecke der nachträglichen Bearbeitung, sondern nur damit die Ausgabe schneller ist.

Wird es nun nur "u.U." gesammelt oder gesammelt wie Siechfred schreibt?
Gruß
Peter

[Struppi]

und genau dieses serielle ausgeben von HTML Code ist ein sehr schlechtes Konzept. u.a. eben weil du dann nichts mehr Rückgängig machen kannst. Wie schon erwähnt, möchtest du entweder die Ausgabe sammeln oder eines der Template Module verwenden, alles andere ist Murks.
Dann besteht das Internet zu 95% aus Murks!
In fast allen Perl-Beispielen - auch in SELFHTML - wird so vorgegangen!

Das sind ja auch, wie du richtigst sagst Beispiele, in der Praxis bekommst du damit früher oder später Probleme.

Das kannst du damit nicht vergleichen, weil es nicht so ist. Die Ausgabe wird zwar u.U. gepuffert (gesammelt), aber nicht zum Zwecke der nachträglichen Bearbeitung, sondern nur damit die Ausgabe schneller ist.

Wird es nun nur "u.U." gesammelt oder gesammelt wie Siechfred schreibt?

Kommt drauf an, ob STDOUT gepuffert ist oder nicht. Das kannst du auch mit Perl ein- und ausschalten.

Struppi.

[Peter]

Hallo,

In fast allen Perl-Beispielen - auch in SELFHTML - wird so vorgegangen!

Das sind ja auch, wie du richtigst sagst Beispiele, in der Praxis bekommst du damit früher oder später Probleme.

Dann appeliere ich an die SELFHTML-ler, Beispiele zu bringen, die praxisbezogen sind!
Oder als Alternative: Hinweis bei den Beispielen
"Vor der Verwendung der Beispiele, fragen Sie Ihren Arzt oder Apotheker ;-)"
Gruß
Peter

[Struppi]

In fast allen Perl-Beispielen - auch in SELFHTML - wird so vorgegangen!

Das sind ja auch, wie du richtigst sagst Beispiele, in der Praxis bekommst du damit früher oder später Probleme.

Dann appeliere ich an die SELFHTML-ler, Beispiele zu bringen, die praxisbezogen sind!

Die Beispiele sind größtenteils ok. Um die Funktionsweise von Methoden zu demonstrieren ist diese vorgehensweise durchaus legitim. Deshalb schrieb ich ja auch früher oder später.

Dir geht es aber um den Ablauf eines CGI Skriptes. In so einem Fallmitten in einem Skript auf STDOUT etwas auszugeben, ist vielleicht für ein kleines Skript noch praktikabel, aber je mehr unterschiedliche Programmabläufe du in dem Skript realisieren willst, umso unpraktischer wird es. Und wie schon gesagt, ab einer bestimmten Größe wirst du um ein Templatesystem nicht mehr umhin kommen.

Letztlich ist es aber eher ein Problem in deiner konkreten Anwendung, wenn du bereits gemachte Ausgaben rückgängig machen willst, dann hast du offenichtlich etwas nicht bedacht als du das Skript entwickelt hast.

Struppi.

[Beat]

Dann appeliere ich an die SELFHTML-ler, Beispiele zu bringen, die praxisbezogen sind!
Oder als Alternative: Hinweis bei den Beispielen
"Vor der Verwendung der Beispiele, fragen Sie Ihren Arzt oder Apotheker ;-)"

Wenn du bei BdE-Online als Mitglied einen Artikel speicherst, dann gelangst du in den Kontext zurück aus dem heraus du die Editfunktion aufgerufen hast. Damit das möglich ist, muss ich tatsächlich alle Daten zuerst abwickeln, bis ich weiss, dann kein "Fehler" (Der text ist zu lange) vorgefallen ist, und ich auch die Datei erfolgreich speichern konnte. Erst dann weiss ich, in welchen Kontext ich dich sende.

Aber immerhin, bis zu diesem Zeitpunkt weiss ich, dass du, egal, was gescheiht, einen normalen HTML Return bekommst, weshalb ich einen teil des HTML Headers raushauen kann.

Es hat einen grund auch, warum ich die reinen Datenabliwcklungen vollziehe und beende, bevor ich den hauptteil raushaue: Da Das Abschliessen des Sessionzyklus davon abhängig ist, will ich das möglichst schnell erledigt haben. Denn das Raushauen über http hat im grunde mit der Userverwaltung nichts mehr zu tun und hat mindere Priorität.

Das als Beispiel, auch wenn ich dir jetzt die 5000 Zeilen Quellcode nicht zeigen werde.

mfg Beat

[Siechfred]

Wird es nun nur "u.U." gesammelt oder gesammelt wie Siechfred schreibt?

Um das nochmal klarzustellen: Struppi spricht vom Puffern von STDOUT (siehe hierzu im Detail Suffering from Buffering). Ich wollte darauf hinaus, dass der Server die HTTP-Response aus den Daten, die er über die CGI-Schnittstelle von irgendeinem Programm erhält, zusammensetzt und verschickt (Ausnahme NPH). Wenn Perl irgendwas nach STDOUT geschrieben hat, dann ist das außerhalb seines Einflussbereiches - gesagt ist gesagt. Wenn Du das umgehen willst, dann nimm ein anderes Konzept, Vorschläge hast Du einige bekommen.

Siechfred

[Peter]

Ich fürchte, ich bleibe bei meinen Datenbankanwendungen, mit dem Wirrwarr im Internet (wenn ich nur an die Normierung denke und die Browser, die sich jeweils nach eigenem Gutdünken daran halten) schlage ich mich besser nicht herum. Das solle andere bei uns erledigen!
Danke trotzdem!

[Struppi]

Ich fürchte, ich bleibe bei meinen Datenbankanwendungen, mit dem Wirrwarr im Internet ..

Und das gibt es bei Datenbanken nicht?
Wenn ich mir das wirrwarr bei MSSQL, mySQL oder Oracle anguck, die sich jeweils nach Gutdünken daran halten.

Alles eine Frage der Erfahrung.

Struppi.