Ankündigung

Einklappen
Keine Ankündigung bisher.

Kurzes Pro & Kontra für Inhaltsfilter und Pagination-art

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Paykoman
    hat ein Thema erstellt Kurzes Pro & Kontra für Inhaltsfilter und Pagination-art.

    Kurzes Pro & Kontra für Inhaltsfilter und Pagination-art

    Hallo Form,

    ich arbeite gerade an einem Auktion-Projekt und setze da gerade das Filtern und und Pagination der Auflistung von Auktionen um.
    Da bin ich jeweils auf 2 Arten gekommen wie man es machen könnte und hätte gern von erfahreneren Usern ein Pro und Kontra zur Umsetzung.

    1) ich kann die vollständige Liste mit data-attribute laden und mit JS die Filter anwenden das entsprechende Elemente ausgeblendet werden. Gilt auch bei Pagination.

    2) Die andere Art wäre bei jeder Änderung am Filter ein Formular zu senden und den Server die Arbeit aufbrummen nur die passenden Auktionen zu laden. Gilt dann auch wieder bei Pagination.

    Was mir spontan dazu einfällt:

    1) Kontra: hat längere Ladezeiten, hohe Last des Clients wenn da 1000 Counter im Hintergrund laufen
    Pro: einfachere Querys, weniger Last für den Server

    2) Dann eben genau umgekehrt.

    Bin mir da echt unschlüßig wie ichs umsetzen soll, Feedback würde mir echt weiterhelfen.

    MfG: Paykoman

    ::EDIT::
    Da fällt mir gerade ein, zur ersten Variante könnte ich den Filter entsprechend erweitern das man das Limit selber einstellen kann, default = 100 und dann einfach ein Dropdown in hunderter Schritte. Wenn dem User noch kein passendes Angebot geliefert wurde, könnte er das Limit selber erhöhen so würde statt 100 eben 200 Auktionen geladen. Hätte zum Vorteil das der Server nicht ständig komplett alle aus einer Kategorie laden muss und die Ladezeit zu mindestens zu Beginn schön schnell ist.

  • hellbringer
    antwortet
    Zitat von Paykoman Beitrag anzeigen
    Und Beitrag 3 ist wenn iches richtig gesehen habe ne API (Ersatz für REST) etc. das ist doch eigentlich was völlig anderes...
    Nein, das ist eigentlich genau das, das man für sowas verwendet. Eine API, die dynamisch Daten ausliefern kann, die anschließend der Browser anzeigt.

    Einen Kommentar schreiben:


  • Paykoman
    antwortet
    Stimmt aber auch hier kann mit JS wieder eine Prüfung bauen, wenn die Seite geblättert wird, kann man einen timestamp der beim laden gesetzt wurde mit einem jetzigen vergleichen und ggf. die Seite neuladen und schwupps hat er die Liste aktuell.

    Sieht aber so aus als würde ich auch nen Websocket hinzubauen der kann die Liste dann auch aktuell halten.

    Das mit den Counter war so angedacht, weil das Skript das ich einsetzte sekündlich das jeweilige Dom-Element anspricht und das würde sich dann mit der hohen Anzahl an Auktionen schon argh den client (Browser) belasten oder?

    Einen Kommentar schreiben:


  • VPh
    antwortet
    Das Problem bei einer rein JavaScript-Seitigen Filterung und Pagination ist ja, dass neue Datensätze nicht in die Anzeige eingeschleust werden. Allein deshalb macht es für mich schon Sinn mit einer Aktion des Users mal den Datenbestand abzufragen.
    "User Henry öffnet früh am Morgen die Auktionsliste; er geht kurz einkaufen, zum Arzt und das Auto waschen... als er sich an den PC setzt und in der Auktionsliste vor und zurück blättert wundert er sich 'na nu, seit 5 Stunden keine neuen Auktionen?'."

    1) Kontra: hat längere Ladezeiten, hohe Last des Clients wenn da 1000 Counter im Hintergrund laufen
    Das mit den "1000 Counter" verstehe ich nicht ganz.

    Einen Kommentar schreiben:


  • Paykoman
    antwortet
    Ja habe aber ja fix den php part dabei gemischt, damit man erkennt was aus der DB geladen wird...
    Das es HTML ist is mir auch klar

    Und Beitrag 3 ist wenn iches richtig gesehen habe ne API (Ersatz für REST) etc. das ist doch eigentlich was völlig anderes...

    Einen Kommentar schreiben:


  • protestix
    antwortet
    Das ist kein Datensatz. Datensätze kommen aus einer Datenbank. Das was du zeigst ist HTML und damit die Ansicht im Browser, das kannst du durchaus dynamisch mit Javascript erstellen lassen, wenn du das möchtest.

    Hellbringer hat in Beitrag #3 ja schon darauf hingewiesen wie man das idealerweise macht, den Hintergrund dazu erfährst du auf Wikipedia.

    Einen Kommentar schreiben:


  • Paykoman
    antwortet
    Zitat von protestix Beitrag anzeigen

    Ja, wenn du nicht in Deutschland lebst geht das sogar schnell, aber es soll ja Regionen geben, die kein Megabit Internet haben und wenn dann der Titel im Durchschnitt nur 50 Byte beträgt, dann überträgst du glatt 5 Megabyte nur an Daten aus dem DBMS ohne Schnickschnack drumherum. Warum sollte man so was wollen?
    Stimmt, ist natürlich auch ein wichtiger Aspekt!

    Einen Kommentar schreiben:


  • Paykoman
    antwortet
    Danke danke, das ist alles schon recht guter Input!

    Zur Datenmenge, ja die ist in der Tat gering...

    Ein Datensatz schaut so aus:
    Code:
    <section id="aucList"> <!-- Container der Liste -->
        foreach( $aucList as $auction ){
            <div class="cal" data-filter-a="<?php echo $auction['a']; ?>" data-filter-b="<?php echo $auction['b']; ?>" data-filter-c="<?php echo $auction['c']; ?>" data-filter-d="<?php echo $auction['d']; ?>">
                <div style="background-image: url('<?php echo $auction['img']; ?>');"></div>
                <div class="aucListData">
                    <div class="clamp"><a href="#"><?php echo $auction['titel']; ?></a></div>
                    <div>
                        <p class="clamp" data-clamp="5"><?php echo $auction['desc']; ?></p>
                        <span><?php echo $auction['country_iso']; ?>- <?php echo $auction[''plz]; ?></span>
                    </div>
                    <div class="auCtn" data-end="<?php echo $auction['date_end']; ?>"></div>
                    <div><?php echo $auction['lastBit']; ?></div>
                </div>
            </div>
        }
    </section>
    Die 4 data-filter entspricht dann auch der DB-Tabellen-Spalte (halt als dummy), das wäre dann eben ausschlaggebend wo JS entscheidet das element aus oder einzublenden.

    Einen Kommentar schreiben:


  • protestix
    antwortet
    Zitat von Thallius Beitrag anzeigen
    Tital der Auktion brauche um zu filtern, dann kann ich durchaus locker 100000 Auktionen direkt laden und danach in Echtzeit filtern
    Ja, wenn du nicht in Deutschland lebst geht das sogar schnell, aber es soll ja Regionen geben, die kein Megabit Internet haben und wenn dann der Titel im Durchschnitt nur 50 Byte beträgt, dann überträgst du glatt 5 Megabyte nur an Daten aus dem DBMS ohne Schnickschnack drumherum. Warum sollte man so was wollen?

    Einen Kommentar schreiben:


  • Thallius
    antwortet
    Zitat von hellbringer Beitrag anzeigen

    Das funktioniert bei kleinsten Datenmengen. Bei größeren Mengen wird der Browser mit Daten zugeschi**en und geht bald in die Knie. Und es dauert sehr lange, bis alle Daten vom Server zum Client übertragen werden.

    Auch wird die Performance wesentlich schlechter sein, außer du implementierst eine eigene Datenindizierung in JavaScript. Sowas kann der Datenbankserver halt schon sehr gut von Haus aus.
    Kleinste Datenmengen ist hier hier aber sehr relativ. Vor allem hängt es stark von der Größe eines Datensatzes ab. Wenn ich zum Beipsiel nur den Tital der Auktion brauche um zu filtern, dann kann ich durchaus locker 100000 Auktionen direkt laden und danach in Echtzeit filtern (z.B. eine sehr schnelle Echtzeitfilterung wenn ich in ein Inputfeld etwas eintippe und dann direkt bei jedem Buchstaben suche. Das wird bei Variante 2 schon deutliche Verzögerungen bringen, während das in Variante 1 in weniger als 100ms erledigt ist und damit für den Benutzer nicht als Verzägerung spürbar.)

    Wenn ich von vornehinein weiß, dass sich meine Anzahl Datensätze nicht großartig ändert (was in diesem Usecase wahrscheinlich nicht der Fall ist), dann kann ich mich durchaus für Variante 1 entschliessen. Ansonsten lieber auf Nummer sicher gehen und für die Zukunft programmieren mit Variante 2

    Gruß

    Claus

    Einen Kommentar schreiben:


  • hellbringer
    antwortet
    Zitat von Paykoman Beitrag anzeigen
    In der ersten Variante würde ja garkein LIMIT gesendet (wie vor dem Edit) und die ganzen Filter (preis, Umkreis etc) sind ja schwerwiegender als Pagination, darum ja dieser Post denn i.d.R. kann ich die Filterung auch von JS übernehmen lassen (ohne Limit und mit js-Pagination wären halt alle items vorhanden).
    Das funktioniert bei kleinsten Datenmengen. Bei größeren Mengen wird der Browser mit Daten zugeschi**en und geht bald in die Knie. Und es dauert sehr lange, bis alle Daten vom Server zum Client übertragen werden.

    Auch wird die Performance wesentlich schlechter sein, außer du implementierst eine eigene Datenindizierung in JavaScript. Sowas kann der Datenbankserver halt schon sehr gut von Haus aus.

    Einen Kommentar schreiben:


  • Paykoman
    antwortet
    Zitat von protestix Beitrag anzeigen
    Auf jeden Fall die 2. Variante.
    Übergebe auch die letzte Id ab der du die Pagination starten willst, da Limit mit zunehmender Anzahl sehr langsam wird.
    Danke schon mal, mir fehlen aber bissl die Pros & Kontras zum Filter

    In der ersten Variante würde ja garkein LIMIT gesendet (wie vor dem Edit) und die ganzen Filter (preis, Umkreis etc) sind ja schwerwiegender als Pagination, darum ja dieser Post denn i.d.R. kann ich die Filterung auch von JS übernehmen lassen (ohne Limit und mit js-Pagination wären halt alle items vorhanden).

    Einen Kommentar schreiben:


  • hellbringer
    antwortet
    Idealerweise setzt man sowas als OData-API um:

    http://www.odata.org/

    Einen Kommentar schreiben:


  • protestix
    antwortet
    Auf jeden Fall die 2. Variante.
    Übergebe auch die letzte Id ab der du die Pagination starten willst, da Limit mit zunehmender Anzahl sehr langsam wird.

    Einen Kommentar schreiben:

Lädt...
X