PHP - Ladezeit mit Meldung überbrücken

Hallo,
das Thema ist nicht ganz neu, jedoch hab ich nach einigen Suchen noch keine zufriedenstellende Lösung gefunden. Mein script braucht einige Sekunden bis das Ergebnis nach einer Formulareingabe bereitsteht. Diese Zeit möchte ich mit einer Meldung überbrücken, die dann verschwindet. Meine jetzige Lösung nutzt Javascript, wenn dies ausgeschaltet ist kommt keine Meldung. Hier der Code:

<style type="text/css">
#bw2 { 
	display:none
	}
</style>

 :

<?php
function html_display($id,$onoff){
echo '<script type="text/javascript">document.getElementById("'.
	$id.'").style.display="'.($onoff ? 'block' : "none").'";</script>'.
	PHP_EOL.(str_repeat(' ',256));
	flush(); //Ausgeben
}
echo '<div id="bw2">Tabelle wird generiert, Bitte warten...</div>';
html_display("bw2",true);
usleep(2000000);
html_display("bw2",false);
echo "Weiter im Text..";
?>

Ohne javascript funktioniert noch ein style im body, ist aber leider nicht valide.
Bin dankbar für Tipps, aber auch zu Kommentaren zum obigen Code.

pit

Ähm, gabs ne Frage?
Mit HTML5 kommen m.E. Fortschrittsbalken :slight_smile:

Die Frage ist, gibt es sinnvolle Alternativen zur obigen Lösung?
Ich brauche keine Fortschritts/Ladebalkenanzeige, möchte nur eine Info geben, daß die Anfrage in Arbeit ist. Am liebsten wäre eine reine CSS Lösung, die auch ohne Javascript funktioniert. Die Zeiten für die ext. Abfrage (Es ist ein Webservice) sind leider sehr unterschiedlich, und ich hab darauf auch keinen Einfluss.

Ich würde dir voschlagen, die Meldung so zu formulieren, dass sie einfach stehen bleiben kann. Wenn der Besucher JS aktiviert hat, verschwindet sie und sonst eben nicht.

Ganz ehrlich kann dir die Meldung allgemein egal sein^^ noJS User sollten einem sowieso egal sein, solange diese die Seite halbwegs benutzen können. Wenn man ne Seite halbwegs Modern/Komfortabel haben will, kommt man halt um JS net herum.

Jedenfalls, die Meldung hier ist nicht nötig, das die Seite läd sieht man ja schon vom Browser aus :wink: [size=85](wenn gleich es z.B. Sinn macht Formulare zu deaktivieren wenn auf Absenden gedrückt wurde, eben um doppeltes zu verhindern. Allerdings muss man zusätzlich noch mal beim Server prüfen :stuck_out_tongue:)[/size]

schliesse mich White-Tiger an, noJS-User sollten JavaScript aktivieren, wenn sie eine Seite mit allen Features nutzen möchten oder die können sonst von mir aus auch ausgesperrt werden. :ps:

Naja^^ Ganz egal sollten sie einem auch net sein :wink:
Sollten halt halbwegs in der Lage sein die Seite zu nutzen, Logins, Chats, Registrationen müssen diese z.B. net können, im Prinzip nur alles was ne Suchmaschine können soll :stuck_out_tongue: [size=85](wobei man wenn möglich Logins und Registrationen auch ohne JS ermöglichen sollte… wobei JS gerade bei Registrationen praktisch sein kann um z.B. Bots/Spam auszusperren)[/size]

PS: weiß eigl. jemand wies beim Impressum aussieht? Man solls ja einfach und mit nem herkömmlichen Browser erreichen können, herkömmliche Browser haben JS an, also darf nen Impressum ohne JS unmöglich zu erreichen / sehen sein?

Wenn du Inhalte hast, die ohne JS zu sehen sind, muss meines Wissens auch das Impressum ohne JS erreichbar sein. Wenn du Text hast, muss es Text und kein Bild sein.

Warum lädst du die Formularanfrage nicht einfach per AJAX ?
Ich mein ist auch Javascript aber nicht so eine misch Ausgabe wie im o.g. Skript…

Dann kannst im Ziel Element ( zb DIV) erstmal einen “Ladeinhalt” oder eine Animation anzeigen, bis der Inhalt geladen ist.

Und für die Meldung für noJS Benutzer erstelle einfach einen Tag, mit der Info das der volle Funktionsumfang nur mit Javascript genutzt werden kann. Es gibt kaum aktuelle und gute Seiten, die ohne Javascript auskommen, schon alleine wegen AJAX und den ganzen Animationen, JS Bibliotheken wie jQuery usw…

Da würde ich die Logik der Behauptung mal umdrehen:
Es gibt keine guten Seiten, bei denen die Deaktivierung der Interpretation von java-script den
Zugang zum Inhalt erschweren würde ;o)
Im Gegenteil, weil die Interpretation von Skripten ja eine Menge Rechenleistung kostet, wird
es eher länger dauern, an Inhalt zu kommen, wenn Skriptinterpretation aktiviert ist ;o)
Ich habe schon zahlreiche so schlechte Skript-Seiten gesehen, die massiv davon profitiert
haben, wenn man Skriptinterpretation (teils sogar CSS) einfach deaktiviert hat, um nicht erst
die Gedanken des Programmierers erahnen zu müssen, was man tun soll, um den Inhalt zu
sehen zu bekommen.

Den Puffer zwischendurch loszuschicken, wenn der server selbst länger braucht, um was
rauszusuchen oder durchzurechnen, kann sicher hilfreich sein - da bietet sich natürlich auch
die Gelegenheit darüber nachzudenken, ob der server das wirklich jedesmal suchen oder
rechnen muß. oder ob man da nicht viel effektiver die Lösung einfach einmal die Woche oder
am Tag rechnen lassen kann und dann aufheben.
Das Absurde am anfänglichen PHP-Skript ist, daß es wegen usleep einfach 2Sekunden nichts
tut, also auch keine weitere Ausgabe erzeugt, das ist ja der Sinn dieser Funktion.
Der jeweilige Nutzer muß also zusätzlich zur Verarbeitungszeit 2 Sekunden warten.
Um gewisse Dinge zu testen, habe ich Ähnliches auch schon verwendet, auf normalen Seiten
möchte man den Inhalt ja doch relativ schnell anzeigen lassen, da sollte man das wohl
vermeiden ;o)

Das generelle Problem liegt darin, daß es allein Sache der browser ist, was sie bei (X)HTML tun,
bis eine Seite komplett geladen ist. Die meisten versuchen schon, zwischendurch mal eine
provisorische Anzeige der bereits vorhandenen Fragmente zu versuchen, das ist aber nirgends
genau festgelegt, also kann es auch keine Methode geben, dafür eine Anzeige reinzumogeln.
Bei einem Format wie SVG tiny 1.2 etwa hat man grob festgelegt, was die Programme
beachten sollen, wenn sie bereits Teile des Dokuments anzeigen wollen, während dieses noch
geladen wird. Da ist das Problem relativ leicht lösbar.

Ich denke, hier geht das auch halbwegs plausibel allein mit (X)HTML+CSS.
Zu Beginn des Dokumentes setzt man im Kopf das CSS im Element style für den Trick
und weit oben im body die Wartemeldung (absolut positioniert). Ziemlich am Ende des
Dokumentes notiert man dann ein Element, welches man ebenfalls absolut positioniert - und
zwar exakt über die Warnmeldung. Der browser kann letzteres erst anzeigen, wenn er hinten
angekommen ist, somit ist die Meldung solange sichtbar, wie der browser nicht hinten
angekommen ist. Da jeder browser natürlich bei (X)HTML machen kann, was er will, bedeutet
es natürlich nicht, daß der nicht auch komplett warten kann, bis alles da ist, bevor was
angezeigt wird, dann wird die Meldung nie sichtbar.
Das Problem hier ist natürlich, daß beides immer angezeigt wird, wenn die Interpretation von
CSS deaktiviert ist, weswegen man den Trick besser so macht, daß man den Text mit der
Eigenschaft content in ein leeres Element einfügt, dann werden die Leute nicht belästigt,
die mit Dekoration und Schnickschnack nichts am Hut haben ;o)

Natürlich könnte man auch entsprechend am Anfang und Ende Skripte für den Trick einbauen,
die ein entsprechendes Element ins DOM einbauen und am Ende wieder entfernen,
weil es aber auch ohne js geht, wozu sollte man das tun? ;o)
Immerhin, wenn man beides per Skript macht, wird auch hier niemand von der Spielerei
belästigt, der kein Interesse an Schnickschnack hat - denn wie bereits erwähnt, der browser
zeigt ja schon an, wenn er mit dem Laden und Darstellen der Seite noch zu tun hat - übrigens
schiebt der browser die Schuld dabei gerne mal auf den server und behauptet, die Seite
würde noch geladen, obgleich das Laden vielleicht nur Sekundenbruchteile benötigt hat, das
Darstellen aber vielleicht einige Sekunden - in solch einer Situation ist natürlich komplett
ungewiß, wann was dargestellt wird, weil das an der Optimierung im browser liegt. Der kann
sich ja erstmal alles herauspicken, was schnell geht.

Ich hätte damit rechnen können das so eine Antwort kommt… -.-*
Du entstellt den Sinn meiner Aussage!

In der Theorie magst du recht haben, in der Praxis gibt es gerade für einen Anfänger wichtigere Dinge - meine Meinung!

Fakt ist AJAX ist ein Thema der Webentwicklung und selbstverständlich realisiert per Skript. Man kann es bedenkenlos verwenden. Bei bedarf kann man Links für Personen bauen, die JavaScript absichtlich abschalten.
Die Umsetzung dazu ist relativ einfach, da der zu ladende Inhalt der selbe bleibt und nur das Template drum herum mit ausgegeben werden muss.
Folglich gibt man dem Link eine JavaScript onClick Funktion und eine href Zielurl.
Wenn der Besucher JavaScript aktiviert verhindert die Funktion per return false die Navigation zur Zielurl und führt stattdessen das Ajax-laden aus.
Andersfalls wird einfach zur Zielurl navigiert.

Von [quote]Zugang zum Inhalt erschweren[/quote] zu sprechen finde ich im Bezug auf den vorherigen Satz überzogen.
Wie gesagt Theorie JA Praxis NEIN.

Ich denke nicht das er sich jetzt auch noch mit SVG auseinander setzen will^^ erstmal eins nach dem anderen.

CSS Positionierung kann bei komplexen Layouts doch relativ einfacher Probleme in unterschiedlichen Browsern verursachen, als es Javascript tut!
Klar ein erfahrener Programmierer kann das verhindern, aber ein Anfänger nicht unmittelbar!

Ich nehme mal stark an du gehörst dazu :wink:

Dekoration - also CSS lasse ich an, soweit es geht. Gibt allerdings einige Seiten, die sind so
schlecht gemacht, daß man auch das deaktivieren muß ;o)
Schnickschnack - kommt drauf an, womit es realisiert ist ;o)
JS - habe ich bei mir unbekannten Seiten deaktiviert - und wenn dann die Seite nicht funktioniert,
werde ich sie in der Regel auch gar nicht mehr näher kennenlernen - und wenn sie funktioniert
gibt es meist keinen Grund, warum man JS aktivieren müßte. So habe ich JS nur vielleicht auf
einer handvoll Seiten laufen, wo das für mich einen Sinn ergibt …

SVG war auch nur ein Beispiel dafür, daß man sowas durchaus definieren kann, wenn die
jeweilige Arbeitsgruppe das für hilfreich und sinnvoll hält - ist eben bei umfangreicher Graphik
offensichtlicher als bei Text, der im Vergleich eher weniger Rechenleistung erfordert, was
allerdings bei massivem Einsatz von CSS und JS nicht mehr der Fall ist - das sind dann aber
teilweise schon wieder ganz andere Leute, die das definieren müßten - und bis die sich
Arbeitsgruppen-übergreifend einig sind, kann sich sowas Jahre oder Jahrzehnte hinziehen ;o)
Von daher lohnt es bei PHP+(X)HTML+CSS besonders, den Kram effektiv zu realisieren, um den
Kram schnell ausgeliefert zu bekommen… Bei PHP+SVG kann es hingegen sein, daß der
browser sowieso erstmal eine halbe bis eine Minute rechnet, um was darzustellen, der server
aber nur Sekundenbruchteile braucht, um was auszurechnen und die Datei zu senden, da
kehren sich die Verhältnisse eben oft um, weshalb es da mehr lohnt, das Verhalten des
browsers besser kontrollieren zu können.

Je nach Dateistruktur wäre es doch am einfachsten, direkt beim Link zu erwähnen, dass das Laden der nächsten Seite einige Sekunden (oder sicherheitshalber Minuten) dauern kann.

Melde mich erst jetzt wieder, da ich mir 1 Woche Urlaub gegönnt habe (und der ist immer Offline… :wink:
@hoffmann: Die Idee mit dem absolut pos. HTML-Element find ich gar nicht so schlecht.
Das usleep im obigen Code ist nur ein Dummy für eine etwas umfangreichere Anfrage an einen externen Webservice, der Code kann so unabhängig getestet werden.
Das Cachen der Anfrage kommt auch nicht in Frage, da die Anfrage stets aktuell sein soll und ein ständiges “Pollen” des externen Servers auch nicht gern gesehen wird.

ach wo wären wir nur immer ohne doc hoff? Ich liebe deine ausführungen, sag mal gibst du auch vorlesungen?? ( svg find eich ja eher uncool aber wer weiß )

naja zum urproblem:
also ich finde die idee mit dem Ajax Request garnicht schlecht, hierfür kann an ja auch gut eine durchdachte Bibliothek wie jquery verwenden.
alternativ: Schon an Caching gedacht? Ich weiß ja net was du da immer abrufst aber evtl lassen sich die Daten ja in einer Datenbank ( oder der performance wegen als flatfile ) abspeichern?

vermutlich eine unsaubere lösung ( vielleciht mag hoffmann noch was dazu sagen? ) aber angucken kann man es sich ja mal:www.auktion-lastminute.de hat auch immer wartescreens ( ebay api abrufe :wink: )

Ajax mag für viele ähnliche Fälle eine Lösung sein, ich muß jedoch Informationen von einem fremden Server holen. Und da man mit Ajax ja nicht direkt Daten von fremden Servern holen kann, müsste ich dafür über ein zweites PHP-Script gehen.
Warum Caching für mich nicht in Frage kommt, hab ich schon erläutert.
Bei aktivierten Javascript (und das sollte der Normalfall sein), funktioniert meine obige Lösung ohne Probleme. Die Idee von Hoffmann bleibt als Ausweg, wenn z.B. in manchen Firmen die Admins Javascript aus Sicherheitsgründen deaktivieren.

ps. hab mal in den link gesehen, da sehe ich mehrere große frameworks (prototype…).
Die nur für das obige Problem einzubinden wäre wie mit Kanonen auf Spatzen zu schießen…

Etwas abstrahiert sieht die Struktur des auszuliefernden Dokumentes doch vermutlich so aus:

a
b
c

Dabei sind a und c relativ schnell zu berechnen und auszuliefern, während b aus welchen
Gründen auch immer auf dem server Zeit braucht (das Problem, daß der browser gelegentlich
viel Zeit braucht, um etwas darzustellen, ist davon unabhängig zu betrachten).
In dem Falle würde man also zwischen a und b exakt einmal den server per PHP auffordern,
bereits vorhandene Inhalte auszusenden. In a könnte man dann einen entsprechenden Hinweis
auf die längere Ladezeit unterbringen, während man in c den Trick unterbringt, den Hinweis
verschwinden zu lassen.

Damit wird nichts getan, um Teile von b schneller auszuliefern, erfordert also auch keine
besonderen Maßnahmen, wenn die Daten in einer Datenbank mühsam zusammengesucht
werden. Insofern wird die einmalige Aufforderung an den server, den Puffer zu senden,
diesen nicht gleich überfordern. Was der browseer mit dem gesendeten Fragment macht,
bleibt natürlich wie erläutert diesem überlassen, jedenfalls hat der dann schon mal Daten,
die eben nicht auf dem server schlafen ;o)

Hardi - ja das bringt quasi die langjährige Erfahrung mit sich und eine gewisse Gelassenheit
gegenüber alltäglichen Problemen, die mich immer wieder einfache und doch originelle
Antworten auf Fragen finden lassen, die ich mir selbst oft gar nicht gestellt hätte, weil das
Problem bei mir so gar nicht aufkommt ;o) Zudem, muß ich zugeben, der zumeist vermutlich
vorhandene Bildungsvorsprung im Zusammenhang mit Ironie macht einige Tips vielleicht für
manchen etwas schwer verdaulich, aber ich habe auch nie behauptet, daß ich ein besonderes
pädagogisches Talent hätte ;o)