Div für Div nachladen

[Jochen]

Hallo,

welche Vorgehensweise empfiehlt sich, wenn ich DIVs einer Webseite nacheinander laden möchte, also DIV2 wird geladen, wenn DIV1 vollständig geladen ist und DIV3 wird geladen, wenn DIV2 vollständig geladen ist?

Meine bisherige Idee ist, DIV1 ganz normal über Jquery "load" zu füllen und über den complete-callback dann das Füllen des DIV2 zu veranlassen usw.

$( "#DIV1" ).load( "ajax/test.html", function() {
    // Und hier sol dann DIV2 nachgeladen werden
});

1. Ist das die sinnvollste Methode?
2. Falls ja, kann ich das Ganze vielleicht als allgemeine Funktion ausgliedern und aufrufen?

Jo

[Der Martin]

Hi,

welche Vorgehensweise empfiehlt sich, wenn ich DIVs einer Webseite nacheinander laden möchte, also DIV2 wird geladen, wenn DIV1 vollständig geladen ist und DIV3 wird geladen, wenn DIV2 vollständig geladen ist?

Meine bisherige Idee ist, DIV1 ganz normal über Jquery "load" zu füllen und über den complete-callback dann das Füllen des DIV2 zu veranlassen usw.

$( "#DIV1" ).load( "ajax/test.html", function() {
    // Und hier sol dann DIV2 nachgeladen werden
});

1. Ist das die sinnvollste Methode?

ob es die sinnvollste Methode ist, kann ich nicht sagen, weil ich mir nicht sämtliche Alternativen vorstellen kann. Es ist zumindet eine Möglichkeit, und sicher nicht die schlechteste.

Was mich viel mehr beschäftigt, ist die Frage nach der Sinnhaftigkeit des Vorhabens an sich. Warum sollte man den Ladevorgang auf diese Weise hinauszögern und ein Schritt-für-Schritt-Laden erzwingen? Internet-Nutzer sind meistens ungeduldig; wenn eine Seite bis zum Fertigladen merklich Zeit braucht, sind viele schon wieder weg. Daher halte ich dein Vorhaben schon im Ansatz nicht für schlau.

2. Falls ja, kann ich das Ganze vielleicht als allgemeine Funktion ausgliedern und aufrufen?

Denkbar, aber knifflig. Immerhin hast du da eine Art Rekursion. Mit nur drei Elementen mag die noch einigermaßen übersichtlich sein - aber wenn es mehr wird, solltest du dir eine schlaue Datenstruktur ausdenken, mit der du das organisierst. Denkbar wäre ein Array aus Objekten, von denen jedes den Ressourcennamen für das nächste Nachladen und die ID des Elements enthält, das neu befüllt werden soll. Bei jedem Aufruf von load() entfernst du den aktuell bearbeiteten Array-Eintrag, bis du mit array.length==0 eine Abbruchbedingung hast.
Überlege dir auch, was du machen willst, wenn bei einem Ladevorgang mal ein Fehler auftritt.

So long,
 Martin

[Jochen]

Hi,

Was mich viel mehr beschäftigt, ist die Frage nach der Sinnhaftigkeit des Vorhabens an sich. Warum sollte man den Ladevorgang auf diese Weise hinauszögern und ein Schritt-für-Schritt-Laden erzwingen? Internet-Nutzer sind meistens ungeduldig; wenn eine Seite bis zum Fertigladen merklich Zeit braucht, sind viele schon wieder weg. Daher halte ich dein Vorhaben schon im Ansatz nicht für schlau.

Doch, genau das halte ich für schlau. Es geht immer noch um die Psycholgogie, wie schnell eine Seite aufgerufen wird.

Überlege dir auch, was du machen willst, wenn bei einem Ladevorgang mal ein Fehler auftritt.

Stimmt. Sollte erst Schritt 2 werden, aber da Du es ansprichst:

$( "#DIV1" ).load( "/ajax/test.html", function( response, status, xhr ) {
  if ( status == "error" ) {
    var msg = "Sorry but there was an error: ";
    $( "#DIV1" ).html( msg + xhr.status + " " + xhr.statusText );
    // Und hier soll dann DIV2 nachgeladen werden
  } else {
  // Inhalt in DIV1 setzen
  // Und hier soll dann DIV2 nachgeladen werden
  }
});

Jo

[Matthias Apsel]

Hallo Jochen,

Doch, genau das halte ich für schlau. Es geht immer noch um die Psycholgogie, wie schnell eine Seite aufgerufen wird.

Du willst also zuerst die Inhalte laden, die auch im Viewport zu sehen sind? Im Allgemeinen wird die Seite so übertragen, wie sie im Quelltext steht. Und wenn ganz vorn der Hauptinhalt steht, machst du schon mal wenig falsch.

So ähnlich machen es Seiten wie facebook, twitter, tumblr, die allerdings auf das scrollevent reagieren: Kurz bevor man am Ende der Seite angekommen ist, werden die nächsten Beiträge nachgeladen.

Bis demnächst
Matthias

[Der Martin]

Hi,

So ähnlich machen es Seiten wie facebook, twitter, tumblr, die allerdings auf das scrollevent reagieren: Kurz bevor man am Ende der Seite angekommen ist, werden die nächsten Beiträge nachgeladen.

ja, so ähnlich macht es auch Google bei der Bildersuche, wenn man Javascript zulässt. Sehr ärgerlich, weil sich die Länge der Seite (abschätzbar anhand des Scrollbalkens) dauernd ändert und man gar keinen Überblick hat, wie weit man eigentlich schon gescrollt hat.

So long,
 Martin

[marctrix]

Hej Der Martin,

So ähnlich machen es Seiten wie facebook, twitter, tumblr, die allerdings auf das scrollevent reagieren: Kurz bevor man am Ende der Seite angekommen ist, werden die nächsten Beiträge nachgeladen.

ja, so ähnlich macht es auch Google bei der Bildersuche, wenn man Javascript zulässt. Sehr ärgerlich, weil sich die Länge der Seite (abschätzbar anhand des Scrollbalkens) dauernd ändert und man gar keinen Überblick hat, wie weit man eigentlich schon gescrollt hat.

Nicht nur das - man kann die noch nicht geladenen Inhalte auch nicht durchsuchen - ärgert mich extrem! - Geschwindigkeit ist eben nicht nur (empfundene) Ladegeschwindigkeit, sondern vielmehr, wie lange ich brauche, um an der intressanten Stelle zu sein!

Und wenn nichts gefunden wird, glaube ich, es ist nicht da (was soll ich auch sonst glauben) und gehe wieder zurück zu Google und teile dadurch mit, dass die Seite doof ist...

Besser man macht die Seite schlank - gut, geht nicht immer, aber meistens.

Marc

[Gunnar Bittersmann]

@@marctrix

man kann die noch nicht geladenen Inhalte auch nicht durchsuchen - ärgert mich extrem!

Bei infinite scrolling kann man aber immerhin alle Inhalte durchsuchen, die man schon geladen hat. Bei paging hingegen nur die momentan angezeigten; die vorher schon angezeigten sind weg.

LLAP 🖖

[marctrix]

Hej Gunnar,

@@marctrix

man kann die noch nicht geladenen Inhalte auch nicht durchsuchen - ärgert mich extrem!

Bei infinite scrolling kann man aber immerhin alle Inhalte durchsuchen, die man schon geladen hat. Bei paging hingegen nur die momentan angezeigten; die vorher schon angezeigten sind weg.

autsch - übel... :-(

Ach so - ist das das Unterteilen eines Artikels auf mehrere Seiten?

Marc

[Der Martin]

Hallo,

Was mich viel mehr beschäftigt, ist die Frage nach der Sinnhaftigkeit des Vorhabens an sich. Warum sollte man den Ladevorgang auf diese Weise hinauszögern und ein Schritt-für-Schritt-Laden erzwingen? Internet-Nutzer sind meistens ungeduldig; wenn eine Seite bis zum Fertigladen merklich Zeit braucht, sind viele schon wieder weg. Daher halte ich dein Vorhaben schon im Ansatz nicht für schlau.

Doch, genau das halte ich für schlau. Es geht immer noch um die Psycholgogie, wie schnell eine Seite aufgerufen wird.

da haben wir wohl unterschiedliche Ansichten. Wenn eine Seite lange zum Laden braucht, ist das schon unangenehm. Wenn in der Zeit wenigstens eine Fortschrittsanzeige läuft ... okay, das macht's etwas erträglicher. Aber besser wäre doch, ich nehme alle künstlichen Bremsen raus. Was du hier vorhast, verlängert aber die Gesamt-Ladezeit erheblich, weil du für mehrere Abschnitte streng sequentielles Laden erzwingst. Also Request absenden, einen kurzen Moment warten, bis die Antwort vom Server eintrifft, dann nächsten Request abfeuern. Bei jedem einzelnen Schritt hast du die kurze Totzeit eines HTTP-Roundtrips.
Die entfällt aber fast völlig, wenn alle Requests gleichzeitig rausgehen, dann können sie nämlich quasi-parallel bearbeitet werden. Und noch besser ist es, das Dokument gar nicht in mehreren Requests anzufordern, sondern in einem Stück. Dann stellt sich das Problem der Wartezeit normalerweise gar nicht. Folgerequests, etwa für Bilder, kommen dann asynchron nach und nach. Die brauchen aber keine Fortschrittsanzeige, weil das Erscheinen eines Bildes sowieso offensichtlich ist.

Mir kommt es daher vor, als versuchst du ein Problem zu lösen, das du vorher selbst geschaffen hast.

Ciao,
 Martin

[Jochen]

Hallo,

Mir kommt es daher vor, als versuchst du ein Problem zu lösen, das du vorher selbst geschaffen hast.

Ich glaube, das liegt gar nicht an mir. Ich versuche, eine Suche, die nacheinander verschiedenen Datenbanktabellen nacheinander nach entsprechenden Lösungen "abgrast", etwas schneller zu machen. Sie bracuht noch nicht mal allzu lange, meist um die 2 Sekunden. Aber ich will den User nicht zwingen, innerhalb der Suche selber zu differenzieren, sondern ihm die Ergebnisse der 8 Teilbereiche in einer Seite anzuzeigen. Das könnte ich aber auch locker in 8x1 oder 4x2 oder "was auch immer" für Teilschritten machen.

Jo

[Rolf b]

Gut, in dem Fall wird es sicher eine schlechte Usererfahrung sein, wenn Du die Seite komplett aufbaust.

Aber es geht Dir doch im Prinzip nur darum, die Serverlast zu begrenzen, oder? Denn die "billige" clientseitige Lösung ist, die 8 Queries blindlings in 8 Ajax-Requests losschicken und die Daten so wie sie kommen auf die Page zu bringen. Nur für den Fall, dass diese 8 Requests den Datenbankserver so sehr belasten, dass es schneller ist, sie sequenziell auszuführen statt parallel, macht eine Lastbegrenzung Sinn (bzw. Du müsstest Dir dann noch ganz andere Fragen zur Lastoptimierung stellen, denn was ist, wenn mehrere User parallel deine Suchseite verwenden).

Kann man einem Webserver nicht konfigurativ mitteilen, wieviele Requests er parallel ausführen darf, bevor er neue Requests in die Warteschlange stellt? Dann hättest Du den Lastbegrenzer nämlich da, wo er hingehört: bei der Serveradministration.

Kleines Problem bei parallen Requests eines Users: Sessiondaten. Den Session-Cookie brauchst Du für die User-Identifikation, aber Ajax-Requests sollten nicht die Sessiondaten verändern, wenn sie parallel laufen können. Hier musst Du aufpassen, es gibt nicht viel ekligeres als parallel laufende Requests auf einer Session, die sich um die Wahrheit der Sessiondaten streiten.

Rolf

[Gunnar Bittersmann]

@@Jochen

Ich versuche, eine Suche, die nacheinander verschiedenen Datenbanktabellen nacheinander nach entsprechenden Lösungen "abgrast", etwas schneller zu machen. Sie bracuht noch nicht mal allzu lange, meist um die 2 Sekunden.

Klingt irgendwie doch lange. Hast du so umfangreiche Daten? Lässt sich vielleicht die Abfrage optimieren?

Aber ich will den User nicht zwingen, innerhalb der Suche selber zu differenzieren, sondern ihm die Ergebnisse der 8 Teilbereiche in einer Seite anzuzeigen. Das könnte ich aber auch locker in 8x1 oder 4x2 oder "was auch immer" für Teilschritten machen.

Sind die Datenbankabfragen unabhängig voneinander und können parallel abgearbeitet werden? Dann könnten die Ergebnisse asynchron zum Client geschickt werden. Was (zuerst) ankommt, wird (zuerst) dargestellt.

Oder willst du die Abfragen nacheinander starten, erst diejenige, deren Ergebnis auf der Seite zuerst (im Sinne von „oben“, nicht zeitlich) dargestellt wird, dann die nächste usw.?

In beiden Fällen solltest du über einen Fallback nachdenken, der ohne JavaScript auskommt.

LLAP 🖖

[Jochen]

Hi,

Sind die Datenbankabfragen unabhängig voneinander und können parallel abgearbeitet werden? Dann könnten die Ergebnisse asynchron zum Client geschickt werden. Was (zuerst) ankommt, wird (zuerst) dargestellt.

Oder willst du die Abfragen nacheinander starten, erst diejenige, deren Ergebnis auf der Seite zuerst (im Sinne von „oben“, nicht zeitlich) dargestellt wird, dann die nächste usw.?

Eigendlich beides: Ja. Prinzipiell sind die Anfragen voneinander unabhängig. Aber der User weiß schon in etwa, wo er den für sich relevaten Ergebnisteil auf der Seite finden wird. Deshalb würde er wahrscheinlich nicht sehr erfreut sein, wenn sich die Reihenfolge ändert.

Jo

[Matthias Apsel]

Hallo Jochen,

Eigendlich beides: Ja.

Eigentlich ;-)

Prinzipiell sind die Anfragen voneinander unabhängig. Aber der User weiß schon in etwa, wo er den für sich relevaten Ergebnisteil auf der Seite finden wird. Deshalb würde er wahrscheinlich nicht sehr erfreut sein, wenn sich die Reihenfolge ändert.

Die Orte auf der Seite können ja auch gleich bleiben. Erreichbar etwa durch die Angabe von Abmessungen für die entsprechenden Elemente.

div {
  display: inline-block;
  width: 42%;
  height: 5em;
}

Dann wird das, was zuerst kommt, zuerst an der gewohnten Stelle dargestellt. Problematisch wird es erst, wenn die umgebenden Elemente größer als der Viewport werden.

Bis demnächst
Matthias

[marctrix]

Hej Matthias,

Prinzipiell sind die Anfragen voneinander unabhängig. Aber der User weiß schon in etwa, wo er den für sich relevaten Ergebnisteil auf der Seite finden wird. Deshalb würde er wahrscheinlich nicht sehr erfreut sein, wenn sich die Reihenfolge ändert.

Die Orte auf der Seite können ja auch gleich bleiben. Erreichbar etwa durch die Angabe von Abmessungen für die entsprechenden Elemente.

div {
  display: inline-block;
  width: 42%;
  height: 5em;
}

Würde noch overflow: auto; hinzufügen, bzw so was benutzen:

.ausgabe {
  display: flex;
  flex-wrap: wrap;
}
.ausgabe > * {
  flex: 1 1 18em;
  max-width: 40em; /* zur besseren Lesbarkeit (nur bei Fließtexten). Wenn die Daten in einer Tabelle ausgegeben werden ist das unnötig */
}

Marc

[Gunnar Bittersmann]

@@Der Martin

Wenn eine Seite lange zum Laden braucht, ist das schon unangenehm. Wenn in der Zeit wenigstens eine Fortschrittsanzeige läuft ... okay, das macht's etwas erträglicher.

Nein.

Was du hier vorhast, verlängert aber die Gesamt-Ladezeit erheblich, weil du für mehrere Abschnitte streng sequentielles Laden erzwingst. […] Bei jedem einzelnen Schritt hast du die kurze Totzeit eines HTTP-Roundtrips.

Was noch hinzukommt: die Kompression. Längerer Quelltext kann stärker komprimiert werden als kürzerer. Die Summe der Teile ergibt eine höhere zu übertragende Datenmenge als das Ganze.

LLAP 🖖