Verständnisfrage: fluid widget paginate

[boy_kottke]

Hallo,

ich hab mal ne Verständnisfrage zum fluid widget "paginate". Es ist ja möglich, bei paginate in der Konfiguration "itemsPerPage" festzulegen, beispielsweise 10 Items pro Seite. Ich habe zusätzlich ein Limit in Extbase gesetzt damit mir nur die 10 neuesten Beiträge angezeigt werden. Ab dem 11. Beitrag kommt nun jedoch keine Blätterfunktion in Paginate mehr zustande. Nun zur eigentlichen Frage: Verzichte ich also auf das setzen des Limits in Extbase, um mit Paginate einen vollständigen Pagebrowser hinzubekommen? und ist das nicht ein wenig unperformant, da ja Extbase die Items an Fluid übergibt? Also: Extbase liest unbegrenzt Items aus der Datenbank und übergibt sie zum rendern an Fluid, welches dann erst die Zahl insgesamt auf 10 begrenzt? Oder wird das durch paginate noch nachträglich begrenzt? Ich verstehe es nicht ganz und würde mich über Feedback zum Thema freuen.

LG

[klaus_ger]

Vielleicht zu besseren Verständnis für Dich.
Wenn Du das Limit in der ExtbAse Query setzt, wird das Datenarray auf beispw. 10 Datensätze beschränkt. Fluid kennt dann natürlich auch nur die 10 Datensätze und zeigt richtigerweise keinen pagebrowser.

Fazit: Limit in der Qurey rausnehmen und alle Datensätze an Fluid übergeben. Der Pagebrowser zeigt dann nur 10 Datensätze an (itemsPerPage = 10) und die Blätterfunktion.

Der interne viewhelper paginate (pagebrowser) ist optimiert und kommt auch mit größeren Datenmengen zügig zurecht. Was er aber definitiv nicht tut, sind neue Querys starten (wie in Deinem Modell angenommen). Die Datensätze müssen schon vom Controller vollständig übergeben werden.

LG Klaus

[boy_kottke]

Hallo Klaus,

Die Frage geht eher bei mri in die Richtung, ob ich Paginate ein vollständiges Array übergeben muss, damit der Pagebrowser funktioniert. Ich entnehme deiner Antwort jetzt mal, dass ja. D.h., dass ich bei theoretischen Datenmengen im höheren Tausenderbereich schlichtweg all diese auch aus der Datenbank entnehmen muss und Paginate zur Verfügung stellen muss, damit Paginate mit den entsprechenden Pagebrowser zusammenbastelt. Und das kommt mir gerade ein wenig unperformant vor, da es sich ja zum Teil um erhebliche Datenmengen handelt. Ist das von der Performance her tatsächlich elegant? Zumal dabei sehr sehr viele Daten geladen werden müssen, die schlichtweg erst einmal für den Eimer sind (zeige zehn von 5000 potentiellen Datensätzen oder so, in meinem Fall geht der Gedanke hin zu einer Dokumentenverwaltung)... Wäre es da nicht sinnvoller, auf Paginate zu verzichten und stattdessen mit einem eigenen Viewhelper zu arbeiten, der beispielsweise einen Zeiger verwendet? Ich denke einfach daran, dass die zur Verfügung gestellte Datenmenge pro anzuzeigender Seite einfach ziemlich groß wird mit der Zeit und das für die Gesamtperformance des Servers vielleicht auch nicht das größte ist...

Vielleicht liegt bei mir auch immernoch ein Denkfehler vor, insofern danke ich dir erstmal für die Antwort und hoffe, dass du mir noch weiter auf die Sprünge helfen kannst.

LG

Thomas

[klaus_ger]

Hallo Thomas,

wenn Du als Beispiel von 5.000 Datenstzen nur 10 zeigen willst, würde ich das auch nicht über den paginator lösen ;), da hätte ich dann auch bedenken mit der Performance.

Für mich machen allerdings auch 5.000 Einträge im Paginator (das wären 500 Seiten, wer blättert die?) wenig Sinn, höchstens vorstellbar bei Gätebüchern o.ä. ...

1. Also entweder die Query einschränken, das nur Datensätze gesucht werden, die nachher auch wirklich benötigt werden, oder alternativ

2. auf paginate verzichten und über eine Controllerfunktion jeweils den nächsten und vorherigen Datensatz suchen und als "Blätterlink" anzeigen. So habe ich das mal in einer Blogextension gelöst, da ich auch nicht alle Einträge aus Performancegründen laden wollte. So brauchst Du nur 3 Datensätze an den View übergeben. Beim "blättern" wird die Function erneut aufgerufen und sucht sich die pasenden Daten.

Falls das Deinen Vorstellungen entspricht, kann ich Dir auch gerne per pn einen Link schicken und den passenden Code.

LG
Klaus

[boy_kottke]

Hallo Klaus,

und 1. ist genau mein Problem: Wenn ich ein Dokumentverwaltungssystem mit FE-User-Schnittstelle baue (Beispiel wäre hier vielleicht sowas wie Deutscher Bundestag - DIP), kann weder die genaue Datenmenge je Abfrage abschätzen noch die Komplexität der Abfrage selbst - und damit ihre "Anzahlgenauigkeit" - da diese ja durch die Suchmaske des FE-Users mitbestimmt wird.

Entsprechend würde ich jetzt mal sagen, da ich schon "googleesk" nen pagebrowser haben will, müsste ich ganz klassisch mit zwei Abfragen im Controller in die Bütt gehen (Count und die limitierte Abfrage), und dann ganz klassisch einen Pagebrowser vielleicht über einen Viewhelper zusammenbauen. Paginate wird dann also eher nix... aber jetzt hab ich es zumindest verstanden... ;)

Über Link und Snippets würde ich mich natürlich freuen... :)

LG

Thomas

[tch9]

Hallo Klaus,

ich habe ein ähnliches Problem mit dem pageinator, würde mich freuen ein Blick auf Deine Lösung werfen zu können:

>2. auf paginate verzichten und über eine Controllerfunktion jeweils den nächsten und vorherigen Datensatz suchen und als "Blätterlink" anzeigen. So habe ich das mal in einer >Blogextension gelöst, da ich auch nicht alle Einträge aus Performancegründen laden wollte. So brauchst Du nur 3 Datensätze an den View übergeben. Beim "blättern" wird die Function >rneut aufgerufen und sucht sich die pasenden Daten.

Ich suche zuerst mit einer eignen SQL-Query "Select...", speiche mir die uid zwischen in ein Array und such dann im Repository nur noch den gefundenen ID aber hier bekomme ich den Fehler #1247602160: Query was empty beim Aufruf der zweiten (x) Seite des pageinators.

Gruß
tch9