nicht angemeldet T-Rex
Der Martin
Der Martin
dedlfix
Der Martin
dedlfix
Der Martin
T-Rex
Der Martin
Hallo!
Ich habe zwei PHP-Dateien:
Normalerweise wird die tuwas.php per Cronjob aufgerufen. Nun würde ich gerne auch in anzeige.php einen Link einbauen, mit der der Besucher die tuwas.php ausführen kann. Aber im Hintergrund. Die tuwas.php soll also nicht im Browser angezeigt werden, als wenn sie mit einem einfachen Link (ohne JS) eingebaut wurde:
<a href="./tuwas.php?benutzer=ich">Klick mich</a>
Vielmehr soll die tuwas.php (die eine Datenbank updatet) einfach ausgeführt werden. Rückmeldung von der tuwas.php bzw. Aktualisierung der anzeige.php nach "Klick" ist nicht erforderlich.
Bei ausgeschaltetem Javascript soll der Link einfach nicht erscheinen. Ich habe jetzt zwar immer "Link" geschrieben, aber vom Prinzip dürfte es auch ein <span>-Element o.ä. sein, welches ich einen Klick-Event verpassen kann.
Ist das so möglich? Wie gehe ich das an?
Gruß
Alex
Hi Alex,
das ist ein Ajax in seiner einfachsten form. Mit Jquery ist das ein klacks.
Wenn du doch eine Lösung ohne JS möchtest, würde ich einen "echten" Link nehmen. Bei Klick wird der Link Target an ein verstecktes Iframe geschickt.
Gruß
Genies finden nun mal doch Lösungen
T-Rex
Hi T-Rex!
das ist ein Ajax in seiner einfachsten form. Mit Jquery ist das ein klacks.
Ich wollte eigentlich verhindern allein dafür Jquery einzubinden. Zwar würde ich das damit wohl sogar leichter hinkriegen als ohne Framework, aber da erscheint mir der Overhead doch etwas groß :-/
Wenn du doch eine Lösung ohne JS möchtest, würde ich einen "echten" Link nehmen. Bei Klick wird der Link Target an ein verstecktes Iframe geschickt.
Darauf bin ich ja garnicht gekommen. Vielen Dank für den Tipp :-)
Gruß
Alex
<a href="./tuwas.php?benutzer=ich" target="frame">Update</a>
<iframe src="about:blank" name="frame" height="0" width="0" frameborder="10"/>
Hallo,
Wenn du doch eine Lösung ohne JS möchtest, würde ich einen "echten" Link nehmen.
ja, genau.
Bei Klick wird der Link Target an ein verstecktes Iframe geschickt.
Nö. Das Script sendet in dem Fall einfach die HTTP-Antwort 204 No Content. Wo keine Antwort kommt, muss sie auch nicht ins Nirwana umgeleitet werden.
Ciao,
Martin
Hallo,
Bei Klick wird der Link Target an ein verstecktes Iframe geschickt.
Nö. Das Script sendet in dem Fall einfach die HTTP-Antwort 204 No Content. Wo keine Antwort kommt, muss sie auch nicht ins Nirwana umgeleitet werden.
ich nutze diese Iframe-lösung anstatt Ajax auch schon lange und funktioniert auch zufriedenstellend. Aber deinen Hinweis hier verstehe ich nicht. Was genau meinst Du damit?
Gruss
Mike
Hi,
Das Script sendet in dem Fall einfach die HTTP-Antwort 204 No Content. Wo keine Antwort kommt, muss sie auch nicht ins Nirwana umgeleitet werden.
ich nutze diese Iframe-lösung anstatt Ajax auch schon lange und funktioniert auch zufriedenstellend. Aber deinen Hinweis hier verstehe ich nicht. Was genau meinst Du damit?
genau das, was ich sagte: Das Script, das auf dem Server angestoßen wird, sendet keine Antwort im eigentlichen Sinn, sondern nur den HTTP-Status 204. Dann weiß der Client: Da kommt nix weiter. In diesem Fall bleibt die aktuell im Browser angezeigte Seite auch stehen, als ob nie ein anderer Request stattgefunden hätte.
Meiner Ansicht nach die eleganteste Methode.
Diese Möglichkeit nutze ich beispielsweise hier im Forum zum Markieren als "gelesen", zum Markieren als "interessant", oder zum Markieren als "fachlich hilfreich".
So long,
Martin
Hallo,
genau das, was ich sagte: Das Script, das auf dem Server angestoßen wird, sendet keine Antwort im eigentlichen Sinn, sondern nur den HTTP-Status 204. Dann weiß der Client: Da kommt nix weiter. In diesem Fall bleibt die aktuell im Browser angezeigte Seite auch stehen, als ob nie ein anderer Request stattgefunden hätte.
genial, habe ich nie gehört, dachte immer das würde den Browser nicht interessieren und er begibt sich immer zur Zielseite.
Meiner Ansicht nach die eleganteste Methode.
sehe ich auch so. Habe noch ein wenig rumgestöbert und ein paar Infos dazu gefunden.
Ein Problem habe ich allerdings dabei, vielleicht hast Du dafür auch eine Lösung:
<?php
file_put_contents('test.txt',file_get_contents('test.txt')*1+1, LOCK_EX);
header("HTTP/1.0 204 No Content");
?>
Obwohl die Seite, die dieses Script per Link aufruft, in UTF-8 ist die erzeugte Textdatei Ansi. Habs dann mal so (utf-8 )probiert wie im Manual beschrieben:
<?php
file_put_contents('test.txt',utf8_encode(file_get_contents('test.txt')*1+1), LOCK_EX);
header("HTTP/1.0 204 No Content");
?>
Immer noch Ansi.
Dann noch ein Versuch:
<?php
header ('Content-Type: text/html; charset=UTF-8');
file_put_contents('test.txt',utf8_encode(file_get_contents('test.txt')*1+1), LOCK_EX);
header("HTTP/1.0 204 No Content");
?>
Ebenfalls noch Ansi, woran liegt das?
Gruss
Mike
Tach!
Obwohl die Seite, die dieses Script per Link aufruft, in UTF-8 ist die erzeugte Textdatei Ansi.
Weder das Betriebssystem noch PHP nimmt irgendeine (Um-)Kodierung beim Schreiben von Dateien vor. Was du da reinschreibst ist allein deine Sache, also auch wie es kodiert ist. Und weil das so ist, wird beim Schreiben (und auch Lesen) von Dateien keinerlei irgendwo gemachte Kodierungsangabe berücksichtigt.
Habs dann mal so (utf-8 )probiert wie im Manual beschrieben:
file_put_contents('test.txt',utf8_encode(file_get_contents('test.txt')*1+1), LOCK_EX);
> Immer noch Ansi.
Woran machst du denn fest, dass es Ansi sei? Was ist denn der Inhalt der Datei und wie sieht er denn in Bytes bei den verschiedenen Kodierungsarten aus?
> Dann noch ein Versuch:
> header ('Content-Type: text/html; charset=UTF-8');
Das ist die Auskunft an den Browser, dass die Kodierung der nachfolgenden Ausgabe UTF-8 sei. Es ist keinerlei Handlungsanweisung für irgendeinen Prozess, UTF-8 zu erzeugen.
> file\_put\_contents('test.txt',utf8\_encode(file\_get\_contents('test.txt')\*1+1), LOCK\_EX);
> header("HTTP/1.0 204 No Content");
> ?>[/code]
Und wenn du 204 und No Content schickst, dann ist eine Kodierungsangabe für etwas nicht vorhandenes überflüssig.
dedlfix.
Hi,
<?php
file_put_contents('test.txt',file_get_contents('test.txt')*1+1, LOCK_EX);
header("HTTP/1.0 204 No Content");
?>
>
> Obwohl die Seite, die dieses Script per Link aufruft, in UTF-8 ist die erzeugte Textdatei Ansi.
zunächst: Was verstehst du unter ANSI? Aus dem Zusammenhang schließe ich, dass du irgendeine von UTF-8 abweichende Codierung meinst, also etwa ISO-8859-x bzw. Windows-1252. Und die Codierung dieser Scriptdatei hat natürlich nichts mit dem Dateiinhalt zu tun.
Der Ausdruck `file_get_contents(...)*1+1`{:.language-php} schreit übrigens nach einem erklärenden Kommentar. Du willst den Dateiinhalt lesen, als Zahl interpretieren und um eins erhöhen? - Meinetwegen. Allerdings schreibst du dann natürlich auch wieder eine Zahl in die Zieldatei zurück. Zahlen bestehen aus Ziffern, eventuell einem Dezimalpunkt und einem Minuszeichen; sehr große oder sehr kleine Zahlen haben vielleicht noch ein 'E' (wie 2.47704E+11). Aber das sind alles ASCII-Zeichen, wo die Frage nach der Codierung noch gar keinen Sinn macht, weil die in Frage kommenden Codierungen (ASCII, ISO-8859-1, ISO-8859-15, Windows-1252, ...) für diese Zeichen alle identisch sind.
> ~~~php
<?php
> file_put_contents('test.txt',utf8_encode(file_get_contents('test.txt')*1+1), LOCK_EX);
> header("HTTP/1.0 204 No Content");
> ?>
Immer noch Ansi.
Was immer das sein mag. Anyway, du meinst "immer noch unverändert". Ja klar, siehe oben. An ein paar Ziffern kannst du keine Zeichencodierung ablesen.
<?php
header ('Content-Type: text/html; charset=UTF-8');
file_put_contents('test.txt',utf8_encode(file_get_contents('test.txt')*1+1), LOCK_EX);
header("HTTP/1.0 204 No Content");
?>
Das ergibt keinen Sinn: Dem Client teilst du mit, dass die Antwort eine in UTF-8 codierte HTML-Ressource sei, gleichzeitg sagst du ihm aber, es gibt keine Antwort.
> Ebenfalls noch Ansi, woran liegt das?
Möglicherweise an einem generellen Missverständnis deinerseits, was Zeichencodierungen angeht. Ich werde aber nicht so recht schlau draus und weiß nicht, wo ich mit einer korrigierenden Erklärung ansetzen muss.
Ciao,
Martin
--
[Mir geht es gut.](http://www.baetzler.de/humor/30_tage_schnee.html) Ich mag die kleinen Pillen, die sie mir dauernd geben.
Aber warum bin ich ans Bett gefesselt?
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
Hallo,
zunächst: Was verstehst du unter ANSI?...Aber das sind alles ASCII-Zeichen, wo die Frage nach der Codierung noch gar keinen Sinn macht, weil die in Frage kommenden Codierungen (ASCII, ISO-8859-1, ISO-8859-15, Windows-1252, ...) für diese Zeichen alle identisch sind.
Meine Editor zeigen Ansi an.
Was immer das sein mag. Anyway, du meinst "immer noch unverändert". Ja klar, siehe oben. An ein paar Ziffern kannst du keine Zeichencodierung ablesen.
Genau so ist es. Sobald Buchstaben drin vorkommen ist es UTF-8, war mir aber nicht bewusst.
Möglicherweise an einem generellen Missverständnis deinerseits, was Zeichencodierungen angeht. Ich werde aber nicht so recht schlau draus und weiß nicht, wo ich mit einer korrigierenden Erklärung ansetzen muss.
Doch doch, alles richtig erkannt. Das mit den Zeichenkodierungen ist tatsächlich etwas verwirrend, weil ich nicht weiß wie und wo die Zeichenkodierung innerhalb einer Datei deklariert wird. Dachte auch wenn nur Zahlen drin wären wäre die Datei unsichtbar mit UTF-8 deklariert, so wie zb. Windows interne Angaben bei BOM reinbaut.
Gruss
Mike
Tach!
Was immer das sein mag. Anyway, du meinst "immer noch unverändert". Ja klar, siehe oben. An ein paar Ziffern kannst du keine Zeichencodierung ablesen.
Genau so ist es. Sobald Buchstaben drin vorkommen ist es UTF-8, war mir aber nicht bewusst.
Nein. Wenn nur Zeichen aus dem ASCII-Bereich vorkommen, gibt es keine Unterscheidung zwischen ASCII, UTF-8 und ISO-8859-x.
Das mit den Zeichenkodierungen ist tatsächlich etwas verwirrend, weil ich nicht weiß wie und wo die Zeichenkodierung innerhalb einer Datei deklariert wird.
Es gibt keine generelle Stelle für die Angabe der Kodierung von Dateien. Das müsste auch irgendwo außerhalb stehen und nicht im Inhalt. Wenn man erst den Inhalt lesen müsste, um an die Kodierungsangabe zu gelangen, müsste man zuerst wissen, nach welcher Kodierung man den Inhalt dekodieren muss, um dann die Kodierungsangabe entziffern zu können. Du siehst die theoretische Unmöglichkeit eines solchen Vorhabens? Das klappt so lediglich bei HTML-Dateien, bei denen festgelegt ist, dass ohne UTF-16/32-BOM die Kodierungsangabe zu ASCII kompatibel in den ersten 512 (oder so) Bytes drinsteht. Für andere Dateiformate mag es irgendein anderes Kennzeichen geben, aber bei Plaintext gibt es rein gar nichts (außer der BOM).
dedlfix.
Hallo Mike,
zunächst: Was verstehst du unter ANSI? [...]
Meine Editor zeigen Ansi an.
ja, das mag sein. Allerdings wird das gern als Sammelbegriff für verschiedene (ähnliche) Codierungen verwendet. Der Artikel, den du verlinkst, erklärt immerhin, dass dort konkret ISO-8859-1 gemeint ist; der Windows-Editor gibt auch "ANSI" an, meint damit aber Windows-1252. Das ist zwar sehr ähnlich zur ISO-8859-Familie, aber manchmal kommt es gerade auf die feinen Unterschiede an, und deshalb möchten wir so ungenaue Wischiwaschi-Begriffe wie "ANSI" hier vermeiden.
Ja klar, siehe oben. An ein paar Ziffern kannst du keine Zeichencodierung ablesen.
Genau so ist es. Sobald Buchstaben drin vorkommen ist es UTF-8, war mir aber nicht bewusst.
Buchstaben im engeren Sinn, also [A-Za-z] reichen noch nicht, wie dedlfix schon erwähnte. Ein Unterschied ist erst feststellbar, wenn Zeichen verwendet werden, die in ASCII nicht vorkommen. Zum Beispiel ü oder é.
Das mit den Zeichenkodierungen ist tatsächlich etwas verwirrend
Ist es teilweise, zugegeben.
weil ich nicht weiß wie und wo die Zeichenkodierung innerhalb einer Datei deklariert wird.
Es gibt da (leider) keine allgemeine Festlegung. Manche Dokumentformate sehen eine Angabe *im Dokument* vor, etwa HTML. Andere kümmern sich gar nicht speziell drum.
Wichtig ist immer:
(A) Beim Erstellen der Datei muss man sich für *eine* Codierung entscheiden und den Text dann tatsächlich in der Codierung speichern. Viele Programme nehmen einem diese Entscheidung ab, weil sie gar keine Auswahl anbieten. Deshalb ist auch vielen Nutzern dieser Schritt nicht bewusst.
(B) Falls das Datei- oder Dokumentformat oder das Übertragungsprotokoll es irgendwo vorsieht, sollte man die Codierung dort angeben - und zwar die, die man tatsächlich verwendet hat, und nicht die, die man gern hätte. Ein häufiges Problem ist etwa, dass Web-Entwickler ihre Dokumente in UTF-8 speichern und auf den Server hochladen, der Server dann aber so konfiguriert ist, dass er ISO-8859-1 angibt (und der Entwickler nicht daran gedacht hat). Die Folge ist, dass sämtliche Nicht-ASCII-Zeichen "kaputt" dargestellt werden.
Ein anderes häufiges Problem ist, dass Laien einfach "UTF-8" hinschreiben und dann meinen, die Datei sei dadurch automatisch umcodiert. Nein! Nur dadurch, dass ich auf eine Sprudelflasche ein Aquavit-Etikett draufklebe, ist noch kein Schnaps drin.
(C) Beim Austausch von Dat(ei)en zwischen verschiedenen Systemen oder Programmen müssen entweder alle beteiligten Komponenten dieselbe Codierung verwenden, oder man muss sie überall explizit angeben, so dass die eine oder andere Komponente die Daten korrekt umschlüsseln kann. Aber Vorsicht: Viele Codierungen lassen sich nicht verlustfrei in andere konvertieren, weil die Ziel-Codierung nicht alle verwendeten Zeichen darstellen kann. Wer beispielsweise hebräische Zeichen in UTF-8 verwendet, wird diese Zeichen verlieren, wenn er nach ISO-8859-x umcodiert, weil diese Zeichen da nicht vorkommen.
Dachte auch wenn nur Zahlen drin wären wäre die Datei unsichtbar mit UTF-8 deklariert, so wie zb. Windows interne Angaben bei BOM reinbaut.
Den Satz begreife ich nicht ganz. Das mit den Zahlen hatten wir ja schon geklärt; die BOM (Byte Order Mark) ist ein spezielles Unicode-Zeichen, das am Anfang von UTF-8-Dokumenten stehen kann (aber nicht muss) und eine eindeutige Erkennung der Codierung erlaubt. Die BOM ist aber optional und führt gelegentlich zu Problemen (z.B. bei PHP-Scripten), so dass allgemein empfohlen wird, diese BOM wegzulassen. Eine darüber hinausgehende Magie hat die BOM aber nicht.
So long,
Martin
Diese Möglichkeit nutze ich beispielsweise hier im Forum zum Markieren als "gelesen", zum Markieren als "interessant", oder zum Markieren als "fachlich hilfreich".
Nach einigem Nachdenken halte ich meine Idee selbst nicht mehr für sooo ideal. Ich möchte nämlich immer ein "ok" oder ein "Fehler" erhalten, welches ich meistens an den User weitergebe.
Wie würdest du einen Fehler abfangen und sichtbar machen? Geht das überhaupt mit dieser Lösung?
Gruß
Ausnahmefehler
T-Rex
Moi,
Nach einigem Nachdenken halte ich meine Idee selbst nicht mehr für sooo ideal. Ich möchte nämlich immer ein "ok" oder ein "Fehler" erhalten, welches ich meistens an den User weitergebe.
Wie würdest du einen Fehler abfangen und sichtbar machen? Geht das überhaupt mit dieser Lösung?
nur eingeschränkt, wenn man dem Script ein Motto beibringt, nach dem viele Menschen auch im Alltag verfahren: "Wenn ich nichts sage, ist alles okay", bzw. "Wenn was schiefgeht, melde ich mich schon".
Mit anderen Worten: Im Erfolgsfall eine schweigsame 204er-Antwort, im Fehlerfall eine ganz normale komplette Seite mit Informationen zum aufgetretenen Fehler.
Allerdings stimme ich auch zu, dass es in vielen Fällen wünschenswert ist, sowohl im Erfolgs- als auch im Fehlerfall eine eindeutige und erkennbare Info zu bekommen.
So long,
Martin
Nach einigem Nachdenken halte ich meine Idee selbst nicht mehr für sooo ideal. Ich möchte nämlich immer ein "ok" oder ein "Fehler" erhalten, welches ich meistens an den User weitergebe.
Das habe ich mir auch nochmal durch den Kopf gehen lassen. Denn die fehlende Rückmeldung wird wahrscheinlich verwirrend für den "Klicker" sein. Das wollte ich zwar erst hinnehmen, weil es sich um eine geschlossene Community handelt, die ich über die Buttonfunktion im Vorfeld informieren könnte; darüberhinaus ist der Button ja nur Optional zum Cronjob, der das Script sowieso ca. stündlich anstößt, dennoch ist eine Rückmeldung natürlich der freundlichere Weg. Ferner könnte ich so den Link nach Klick auch deaktivieren/ersetzen, so dass das Script nicht ständig angestoßen wird, weil der Benutzer sich nicht sicher ist, ob was gemacht wurde oder nicht. Also werde ich nun doch etwas mit AJAX umsetzen :)
Nach einigem Nachdenken halte ich meine Idee selbst nicht mehr für sooo ideal. Ich möchte nämlich immer ein "ok" oder ein "Fehler" erhalten, welches ich meistens an den User weitergebe.
Das habe ich mir auch nochmal durch den Kopf gehen lassen. Denn die fehlende Rückmeldung wird wahrscheinlich verwirrend für den "Klicker" sein. Das wollte ich zwar erst hinnehmen, weil es sich um eine geschlossene Community handelt, die ich über die Buttonfunktion im Vorfeld informieren könnte; darüberhinaus ist der Button ja nur Optional zum Cronjob, der das Script sowieso ca. stündlich anstößt, dennoch ist eine Rückmeldung natürlich der freundlichere Weg. Ferner könnte ich so den Link nach Klick auch deaktivieren/ersetzen, so dass das Script nicht ständig angestoßen wird, weil der Benutzer sich nicht sicher ist, ob was gemacht wurde oder nicht. Also werde ich nun doch etwas mit AJAX umsetzen :)
Es kann hier nur zwei grundsätzliche Lösungen geben. Entweder man wartet bis zum Ende der Ausführung des scripts und sendet dann auf irgendeine Weise die Information, z.B. indem man die Seite auf der man das script ausgelöst wurde noch mal sendet, ergänzt um die Information.
Oder man läßt das script arbeiten bis es fertig ist, ohne, daß es aktiv was sendet, und die Information wird beim nächsten Aufruf der dafür vorgesheenen Seite angezeigt, sofern das script zu dem Zeitpungt fertig ist. Z.B. im Kopf der Seite die Statusnachricht "letzte Aktualisierung von haumichblau erfolget am, um".
Die Ausführung des scriptes kann man davon abhängigmachen, daß es gerade nicht ausgeführt wird und das Ende seiner letzten Ausführung noch keine x Zeiteinheiten her ist.
Hello,
Es kann hier nur zwei grundsätzliche Lösungen geben. Entweder man wartet bis zum Ende der Ausführung des scripts und sendet dann auf irgendeine Weise die Information, z.B. indem man die Seite auf der man das script ausgelöst wurde noch mal sendet, ergänzt um die Information.
Das ist im HTTP/s-Protokoll nicht vorgesehen. Verbindungsende bleibt Verbindungsende!
Oder man läßt das script arbeiten bis es fertig ist, ohne, daß es aktiv was sendet, und die Information wird beim nächsten Aufruf der dafür vorgesheenen Seite angezeigt, sofern das script zu dem Zeitpungt fertig ist. Z.B. im Kopf der Seite die Statusnachricht "letzte Aktualisierung von haumichblau erfolget am, um".
In welchem "Kopf"?
Habe ich den passenden Endruck, wenn ich annehme. dass Dir die Begriffe "vierte Dimension" und "verteilte Aufgaben" noch nicht geläufig sind?
MMn geht es hier genauer betrachtet doch darum, dass ein Prozess zeitweise die Kontrolle über andere (Child-)Prozesse aufgeben mag ("im Hintergund ausführen") aber diese Kontrolle ggf. anhand von Metadaten später einmal wieder aufnehmen mag?
Der OP täte daher gut daran, ein Prozess-Zeitdiagramm anzufertigen und das mit einem Kontroll-Prozessdiagramm und einem Kontroll-Zeitdiagramm zu vergleichen und eventuell weiteren in Bezug zu setzen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Es kann hier nur zwei grundsätzliche Lösungen geben. Entweder man wartet bis zum Ende der Ausführung des scripts und sendet dann auf irgendeine Weise die Information, z.B. indem man die Seite auf der man das script ausgelöst wurde noch mal sendet, ergänzt um die Information.
Das ist im HTTP/s-Protokoll nicht vorgesehen. Verbindungsende bleibt Verbindungsende!
Keine Ahnung worauf Du hinauswillst. Ich habe an dieser Stelle jedenfalls nicht vorgeschlagen etwas nach einem Verbindungsende zu senden. Das "warten" meint warten, also die Verbindung nicht abzubrechen, bis zum Vorliegen des Ergebnisses.
Oder man läßt das script arbeiten bis es fertig ist, ohne, daß es aktiv was sendet, und die Information wird beim nächsten Aufruf der dafür vorgesheenen Seite angezeigt, sofern das script zu dem Zeitpungt fertig ist. Z.B. im Kopf der Seite die Statusnachricht "letzte Aktualisierung von haumichblau erfolget am, um".
In welchem "Kopf"?
In dem der Seite, steht doch da. Man kann es aber auch in den Fuß schreiben oder irgendwo dazwischen.
Habe ich den passenden Endruck, wenn ich annehme. dass Dir die Begriffe "vierte Dimension" und "verteilte Aufgaben" noch nicht geläufig sind?
Ich habe den Eindruck, dein Eindruck ist nicht zutreffend.
Ich schlage vor eine Arbeit zu beginnen, und auf Anfrage das Ergebnis anzuzeigen sofern es bereits vorliegt.
Hello,
genau das, was ich sagte: Das Script, das auf dem Server angestoßen wird, sendet keine Antwort im eigentlichen Sinn, sondern nur den HTTP-Status 204. Dann weiß der Client: Da kommt nix weiter. In diesem Fall bleibt die aktuell im Browser angezeigte Seite auch stehen, als ob nie ein anderer Request stattgefunden hätte.
Meiner Ansicht nach die eleganteste Methode.
Bist Du dir sicher, dass das Script nach dem Senden des Status 204 auch noch zuende läuft? Das könnte ja durchaus noch einige Sekunden dauern.
MMn darf der Browser nach dem Erhalt von Status 204 nämlich die Verbindung kappen. Und das kommt dann einem Userabort gleich. Der würde zumindest bei PHP (was ja hier auch im Gespräch war), die Beendigung des Scriptes zur Folge haben. Das ist dann aber mit seiner Arbeit eventuell noch gar nicht ganz fertig...
Besser erscheint es mir wirklich, dass man es wirklich in den Hintergrund stellt.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hallo Tom,
genau das, was ich sagte: Das Script, das auf dem Server angestoßen wird, sendet keine Antwort im eigentlichen Sinn, sondern nur den HTTP-Status 204. Dann weiß der Client: Da kommt nix weiter. In diesem Fall bleibt die aktuell im Browser angezeigte Seite auch stehen, als ob nie ein anderer Request stattgefunden hätte.
Meiner Ansicht nach die eleganteste Methode.
Bist Du dir sicher, dass das Script nach dem Senden des Status 204 auch noch zuende läuft?
ähm, ja. Kommt drauf an.
Eigentlich gehe ich davon aus, dass das Script erst seine Arbeit erledigt, und dann *zum Schluss* seine Antwort gibt. Also entweder ein 204er-Status, wenn alles in Ordnung war, oder eben eine Seite, die Informationen zum Fehler gibt.
MMn darf der Browser nach dem Erhalt von Status 204 nämlich die Verbindung kappen. Und das kommt dann einem Userabort gleich. Der würde zumindest bei PHP (was ja hier auch im Gespräch war), die Beendigung des Scriptes zur Folge haben.
Gerade bei PHP nicht. Zumindest wenn man's auf herkömmliche Weise mit header() macht, wird dadurch ja nur der zu sendende HTTP-Header vorbereitet und im Ausgabepuffer bereitgestellt. Endgültig zum Client geschickt wird das Zeug aber erst, wenn das Script Ausgaben macht oder beendet wird.
Zugegeben, wenn wir von Scripts reden, die wirklich mehrere Sekunden Laufzeit haben, ist die Methode nicht wirklich schön.
So long,
Martin
Hello,
Bist Du dir sicher, dass das Script nach dem Senden des Status 204 auch noch zuende läuft?
ähm, ja. Kommt drauf an.
Eigentlich gehe ich davon aus, dass das Script erst seine Arbeit erledigt, und dann *zum Schluss* seine Antwort gibt. Also entweder ein 204er-Status, wenn alles in Ordnung war, oder eben eine Seite, die Informationen zum Fehler gibt.MMn darf der Browser nach dem Erhalt von Status 204 nämlich die Verbindung kappen. Und das kommt dann einem Userabort gleich. Der würde zumindest bei PHP (was ja hier auch im Gespräch war), die Beendigung des Scriptes zur Folge haben.
Das ist aber die Unsicherheit. Der Client-User wartet auf Antwort, die aber nicht kommt, weil das Script noch nicht fertig ist. Also wird er nervös, und lädt ddas Dokument nochmal. Damit wird das noch laufende Script abgebrochen und nochmals gestartet. Sollten da nun umfangreiche Datenveränderungen dahinter liegen, werden die teilweise doppelt ausgeführt, was i.d.R. zur Inkonsistenz der Daten führt.
Gerade bei PHP nicht. Zumindest wenn man's auf herkömmliche Weise mit header() macht, wird dadurch ja nur der zu sendende HTTP-Header vorbereitet und im Ausgabepuffer bereitgestellt. Endgültig zum Client geschickt wird das Zeug aber erst, wenn das Script Ausgaben macht oder beendet wird.
Das stimmt allerdings auch wieder, wenn man keine Header-Ausgabe erzwingt. Dann bleibt die angezeigte Seite im Browser aber solange "blockiert", bis diese Ausgabe kommt.
Ich denke, dass genau das nicht erwünscht war von Alex.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Also wird er nervös, und lädt ddas Dokument nochmal. Damit wird das noch laufende Script abgebrochen und nochmals gestartet. Sollten da nun umfangreiche Datenveränderungen dahinter liegen, werden die teilweise doppelt ausgeführt, was i.d.R. zur Inkonsistenz der Daten führt.
Da der Fall ggf. ohnehin abgefangen werden muß, ist das kein Argument gegen die Methode.
Hello,
Also wird er nervös, und lädt ddas Dokument nochmal. Damit wird das noch laufende Script abgebrochen und nochmals gestartet. Sollten da nun umfangreiche Datenveränderungen dahinter liegen, werden die teilweise doppelt ausgeführt, was i.d.R. zur Inkonsistenz der Daten führt.
Da der Fall ggf. ohnehin abgefangen werden muß, ist das kein Argument gegen die Methode.
Welche "Methode"?
Ich konnte hier bisher noch keine erkennen, wobei ich hier vom Urbefriff ausgehe:
https://de.wikipedia.org/wiki/Methode_(Erkenntnistheorie)
Eine "Methode" sollte mMn ein reproduzierbares und definierbares Verhalten mit definierbaren Zielen unter bestimmten Randbedingungen definieren, und nicht "irgendein" Verhalten beschreiben, dass "vielleicht" eintreten könnte...
Wenn das Endergebnis also fraglich belibt, sollte man die möglichen und notwenigen Arbeitsschritte zu den entsprechenden Rahmenbedingungen neu überdenken!
Das nenne ich dann "methodisches Verhalten" :-O
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Welche "Methode"?
Die beschriebe.
Hallo,
Welche "Methode"?
Ich konnte hier bisher noch keine erkennen, wobei ich hier vom Urbefriff ausgehe:
https://de.wikipedia.org/wiki/Methode_(Erkenntnistheorie)
die 204er Methode
Eine "Methode" sollte mMn ein reproduzierbares und definierbares Verhalten mit definierbaren Zielen unter bestimmten Randbedingungen definieren, und nicht "irgendein" Verhalten beschreiben, dass "vielleicht" eintreten könnte...
Ist doch kein vielleicht. Ich bin froh, dass ich diese Möglichkeit hier erfahren habe, sehr nützlich.
Wenn das Endergebnis also fraglich belibt, sollte man die möglichen und notwenigen Arbeitsschritte zu den entsprechenden Rahmenbedingungen neu überdenken!
Das nenne ich dann "methodisches Verhalten" :-O
Na dann sollte man mal einiges überdenken, zb. Auszeichnungen in HTML:
<form method="post"....>
Das ist dann wohl auch keine Methode, denn das Endergebnis bleibt fraglich. Nicht fraglich bleibt aber der Request, wie 204er ;-)
Gruss
Mike
Ich weiß ja nicht, welcher Gedankengang hinter dem Wunsch steckt, aber die tuwas.php einfach von der anzeige.php aufrufen zu lassen ist eventuell adäquat.
Ansonsten unterstütze ich die Lösung mit normalem Link ohne frame. Außer das nicht Erscheinen des Links bei ausgeschaltetem JS gehört widererwartend zur gewollten Funktionalität. Dann kann man den normalen Link aber auch mit JS einblenden, wenn man sich kein Jquery ans Bein hängen will.
Hello,
hier ein paar Links aufs Archiv:
http://forum.de.selfhtml.org/archiv/2012/6/t209968/#m1429346
http://forum.de.selfhtml.org/archiv/2010/6/t198495/#m1333275
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg