Hallo!

Hier mal die Fortsetzung des Feature-Requests zum Paging als Core-Funktionalität.

Die Idee hinter dem ganzen, ist es eine Gruppe von MOD_VALUE[] zu schaffen, die nicht nur im Modul, sondern auch im Core ausgewertet werden. Andersrum gibt es auch eine Gruppe solcher Werte, die der Core an das Modul zurück gibt.

Nachdem ich festgestellt habe, dass ja die Bezeichnung nicht rein nummerisch sein muß, habe ich mich entschieden, diese in der Form 'cms:identifier' zu benennen, um sie von normalen MOD_VALUE[]-Werten zu unterscheiden.

Moment hab ich nur zwei Variablen eingebaut, die für das Paging benutzt werden

Diese sind:

cms:paging
Diese teilt Sefrengo mit, dass man den Inhalt eines Containers nur teilweise ausgeben möchte.

cms:items_per_page
Teilt Sefrengo dann mit, wie lang der auszugebende Teil ist.

In der Konfiguration des Moduls sieht das ganze dann wie folgt aus:



Vorteil:
Das Modul braucht sich nicht mehr um die Aufteilung des Contents zu bemühen, Sefrengo übernimmt das. Dadurch wird nicht unwesentlich Speicher gespart.


Im Gegenzug ermittelt der Core für das Modul einige wesentliche Daten für die Seitennavigation: Anzahl der Elemente, und die aktuell dargestellt Seite.

MOD_VALUE[cms:elements]
Steht im Modul zur Verfügung und enthält die Gesamtzahl der Elemente.

MOD_VALUE[cms:akt_page]
Enthält die aktuell dargestellte Seite, die Zählung beginnt mit 1. Der Core liest dazu im Request eine Variable aus, deren Name in den Einstellungen der jeweiligen Sprache eingestellt werden kann.

Frage: Macht das Sinn, das Sprachabhängig zu machen? Muß das überhaupt wählbar sein?

In der Frontendausgabe des Moduls können diese Werte dann verwendet werden:



Oder komplexer, um eine Navigation aufzubauen (Der Code ist nicht getestet und nur als Beispiel zu verstehen!):



Damit sollte es Modulautoren wesentlich leichter sein, eine Seitennavigation in ihren Modulen zu integrieren. Darüber hinaus werden noch die Resourcen (=Speicher) geschont, da nur das verarbeitet werden muß, was auch dargestellt wird.

Notwenig dafür ist zum einen eine angepaßte inc.generate_code.php, zum anderen kleine Fixes im SQL der Sprachanlage und Installation, und an der Sprachdatei lang_clients_config.php.

Die beigelegte inc.generate_code.php verwendet hardcoded die Request-Variable 'page' um leicht testen zu können.

Was auch noch fehlt ist:

• Paging für's Backend, klappt zur Zeit nur im Frontend, im Backend wird immer alles angezeigt, warum auch immer
• Unterstützung für mod_rewrite (keine Ahung wie das geht!)

Ich häng auch ein triviales Testmodul an, mit dem man das ganze mal leicht testen kann.

Und so sieht das im Frontend aus:



Und jetzt bitte Vorschläge, Tipps, Meinungen...

Tschüss
Tiggr

Hiho!

Ok, hab mehr Ergebnisse und gebe mich geschlagen! :-(

Erstmal was geht: Es paged auch im Backend!

Und nun das Problem:

Das Problem ist das Caching. Bei eingeschaltenem Frontendcache kann man soviel in der Navi hin und her klickern wie man will, man sieht immer das selbe, den gecachten Inhalt!

Ich hab jetzt mein Sefrengo so gehackt, das es die einzelnen Unterseiten cached, war garnicht mal so übel zu machen, mußte nur eine neue Spalte 'idpage' in der Tabelle cms_code einfügen, und an einigen wenigen Stellen das SQL etwas anpassen.

Nun werden die einzelnen Seiten gecached. Wunderbar! Denkt man! Aber ein großes Problem gibt es, es unterläuft den Freigabemechanismus von Sefrengo.

Folgender Ablauf: Es war noch nie jemand auf der Teilseite 5 der Seite. Nun hängt da ein Redakteur da einen neuen Blog-Beitrag an. Alle im Cache stehenden Teilseiten werden auf geändert aber nicht publiziert gestellt. Diese werden im alten Stand ausgeliefert, nur leider nicht die Teilseite 5, weil die ist ja noch nicht im Cache! Besucht nun ein normaler Seitenbesucher die Teilseite 5 bekommt er die aktuellen, noch nicht freigegebenen Inhalte gezeigt, da die Seite ja nicht im alten Zustand im Cache zu finden war! :-(

Ergebnis:
Man kann die Optimierung, wie ich sie mir vorstelle durchführen, mit erstaunlich wenig Aufwand. Aber dann kommen systembedingte "Mängel" zustande, die immer mehr Änderungen nach sich ziehen!

Für mich selber wäre das Ergebnis zwar fast ok, aber ich werde es wohl doch in die Tonne kloppen, und was anderes probieren!

Noch schlimmer wird das ganze, wenn man die "Seitenlänge" variabel gestalten möchte, und man dem Seitenbesucher entscheiden lassen würde, wie viele Elemente auf einer Seite zu finden sind, dann ginge garnichts mehr mit Cache!

Mein persönliches Ergebnis: Netter Versuch, aber leider für'n Ar...!

Zumindest hab ich was über Sefrengo gelernt!

Tschüss
Tiggr

Bevor ich es lösche, hier mal alle von mir geänderten Dateien!

Was fehlt ist die neue Spalte "idpage" in der Tabelle cms_code, und die Einstellung in der Sprache für die Request-Variable.

Dabei ist auch der angepasste MrList und ein Testmodul!

Tschüss
Tiggr

Aber trotzdem, toller Versuch, Kompliment.

Wäre auf jeden Fall schön, wenn Du bei der Speicherreduzierengeschgichte dran bleiben würdest. Da etwas zu optimieren würde sicher vie bringen.

Zum Paging und dem ganzen con_edit Bereich:
Insgesamt ist das sehr komplex und hat leider ein paar heftige Haken, die sich erst beim genaueren Hinsehen offenbaren. Der gesamte Seiten und Contentbereich steht auch für Sefrengo 1.6 auf der Prioritätenliste.

Damit das Paging vernünftig funktioniert müssen auch noch folgende Bedingungen erfüllt werden:
- Die cms:tags funktionieren zur Zeit nur bei aktiviertem Cache. Sefrengo muss so klug reagieren, das auch in nicht gecachten PHP die Anfragen verarbeitet werden können
- Beim Paging muss die cms_content Tabelle beachtet werden. Das hattest Du ja schon gesehen. Ein Paging bringt bei 1000 Einträgen überhaupt nichts, wenn im Hintergrund immer die komplette cms_content Tabelle für die entsprechende Seite geladen wird.

Ich stelle mir das zukünftig so vor, das ein Modul auf ein Objekt zugreift , welchen Informationen übergeben werden kann, welche Wiederholungsschleifen des Moduls benötigt werden. Das ganze könnte eine Mischkalkulation sein, die folgendermaßen funktioniert:
- es werden standardmäßig immer die ersten 10 Iterationen der cms_content geladen.
- Innerhalb dieser Iterationen kann das das Modul mit Sefrengo kommunizieren, in welche Iteration es springen will.

Beispiel:
Gehen wir einfach mal davon aus, es soll Iteration 120-130 von Insgesamt 1000 ausgeführt werden:
1) Beim ersten Durchlauf des Moduls wird das gesetzt: $obj->setJumppoint(120); $obj->setPointOfExit(130);
2) Nach Beendigung des ersten Durchlaufs checkt Sefrengo $obj und weiß das es das Modul ein wenig vorspulen muß
3) Sefrengo generiert den benötigten Content und führt das Modul ab Sprungpunk 120 10 mal aus
4) Nach Iteration 130 wird das Modul beendet

was dabei aus meiner Sicht auch sinnvoll wäre ist, das es für jedes Modul einen zusätzlichen Bereich gibt, welcher nur 1mal ausgeführt und integriert wird egal wie viele Wiederholungen des Moduls ausgegeben werden. Dort könnten das Classen oder Funktionen abgelegt werden welche in den einzelnen Wiederholungen verwendet werden. Dadurch kann ein grosser Teil des Speicherverbrauchs reduziert werden. Dazu werde ich später noch etwas schreiben.

Ich werde dazu noch einen FR schreiben.

Gruss
Mistral