Hilfe - Suche - Mitglieder - Kalender
Vollansicht: Paging als Sefrengo-Funktion
Forum Sefrengo.org > Allgemeine Foren > Feature Request
Tiggr
Hallo!

Angeregt durch die Diskussion um MrList und ContentFlex und deren Seitennavigationen hab ich mal versucht, wie schwer es ist, sowas als direktes Feature von Sefrengo rein zu frickeln.

Ergebnis: Es geht, einfach als ich dachte, aber mit ein paar Kompromissen. Ich habe versucht möglichst flexible zu bleiben, und natürlich auch kompatibel.

Hier mal mein Stand der Dinge, meine Entscheidungen und Probleme:

Im Frontend kann ich schon bei sich wiederholenden Modulen (habs bisher an einer Textzeile ausprobiert, müßte aber mit jedem anderen auch tun) einen Teilbereich darstellen. Ist im Moment noch hart im Code hinterlegt welcher Bereich, aber es tut! Müßte jetzt anfangen den Bereicht aus dem Request zu holen. Weiß nicht, was da der richtige Sefrengo-Weg ist.

Dafür mußte ich nur etwas in der Datei inc.generate_code.php rumhacken.

Zum zerlegen in einzelne Teile benutze ich eine einfache Schleife, die aus dem $content-Array das rausholt, was ich brauche! (array_slice wollte irgendwie nicht...)

QUELLTEXT
// alle Module in einem Container generieren
if(is_array($content[$cms_mod['container']['id']])){
    // <ME>
    // Array für Paging kürzen, falls sinnvoll!
  if ($cms_mod['container']['cms:paging'] == 'true') {
      
       // test
       $start = 2;
       $length = 5;
       // test
      
       $newcontent = NULL;
       $count = 0;
       if (count($content[$cms_mod['container']['id']]) > 1) {
             foreach ($content[$cms_mod['container']['id']] as $key3 => $value3) {
           if ($count >= $start && $count < $start+$length) {
               $newcontent[$cms_mod['container']['id']][$key3] = $value3;
           }
           $count++;
          }
       } else {
            $newcontent = $content;
       }
  } else {
       $newcontent = $content;
  }
  // </ME>

    $first = true; // ME
    foreach ($newcontent[$cms_mod['container']['id']] as $key3 => $value3) {
        // letztes Modul in diesem Container?


Für das Backend gibt es da wohl irgendwo eine eigene Stelle!? Hat bei mir zumindest keine Auswirkung auf das Backend! Erstmal egal!

Woher weiß Sefrengo nun, welchen Container es zerhacken soll? Dafür hab ich etwas an der Modul-Konfiguration gedreht. Ich hab da cms:*-Variablen erfunden. Im besonderen eine cms:paging, ist diese auf 'true' gesetzt, wird der Container dieses Moduls zerschnitten. Das sieht im Modul wie folgt aus:

QUELLTEXT
// Paging aktivieren/deaktivieren
$mip_form['cms:paging']['desc'] = 'Inhalte auf mehrere Seiten aufteilen und Navigation anzeigen?';
$mip_form['cms:paging']['cat'] = 'chk';
$mip_form['cms:paging']['option_var']['0'] = 'MOD_VAR[cms:paging]';
$mip_form['cms:paging']['option_val']['0'] = $dedi_mod['value']['cms:paging'];
$mip_form['cms:paging']['option_desc']['0'] = 'ja';
$mip_form['cms:paging']['option_val_select']['0'] = 'true';


So kann das Modul Sefrengo mitteilen: Zerhack mich! ;-) Ich dachte das sei der Weg mit der größten Flexibilität und den geringsten Problemem, wenn man Module nachrüsten möchte.

So geht's jetzt erstmal! Was mir noch nicht ganz klar ist sind folgende Probleme:
  • Wie bau ich den Pager in die Seite ein? Ich will auch hier wieder möglichst wenig in Sefrengo und die Module eingreifen.
  • Wie bekomme ich die Werte für $offset und $length elegant über den Request, mod_rewrite kompatibel und mit geringem Aufwand?
Ich hab das ganze mal ausführlicher dargestellt, auch wenn man dann wohl schnell sieht, das PHP für mich neu ist und auch Sefrengo. Hab aber viel über das System gelernt heute! ;-) Worum es mir geht, bevor ich mich da richtig reinknie, ist folgendes:

Könntet Ihr euch vorstellen, sowas in den Core von Sefrengo aufzunehmen? Oder wäre sowas nur eine private Friggle-Lösung von mir? Falls Ihr es für sinnvoll erachtet, ist dann mein Vorgehen halbwegs sinnvoll, oder geht das einfacher, besser, eleganter?

Gebt euren Senf dazu ab, falls Ihr das für den falschen Weg haltet, dann überlege ich ein Blog/News-Plugin zu schreiben, um MrList als Blog-Tool abzulösen. Oder ich warte bis da das Speicherproblem gelößt ist!

Ich persönlich glaube aber, das ein einheitlicher paging-Mechanismus in Sefrengo sehr sinnvoll wäre!

Tschüss
Tiggr

PS: Ich häng die von mir gequälte Datei an, alle Änderungen von mir sind mit // ME oder <ME>...</ME> markiert!
bkm
Ist nicht eine Art der Seitenschaltung (-navigation) schon in der GUI =>Page (API)
sf_factoryGetObject('GUI', 'Pager');
enthalten ?
Tiggr
Hiho!

QUELLTEXT
Ist nicht eine Art der Seitenschaltung (-navigation) schon in der GUI =>Page (API)
sf_factoryGetObject('GUI', 'Pager');
enthalten ?


Ganz ehrlich, keine Ahnung! Mir fehlt momentan komplett der Überblick was Sefrengo schon kann, und was nicht. Ich kenn' nur die Diskussion ums Paging von ContentFlex, da war das noch ein Wunsch, das sowas rein kommt!

Tiggr
Tiggr
Nochmal Hallo!

Stimmt, hast recht, gibt in der GUI auch ein Pager-Objekt, gleich mal damit rumspielen!

Tiggr
Tiggr
Hiho!

OK, funktioniert sogar sehr gut! :-)

Hat nicht viel Arbeit gemacht:

QUELLTEXT
$req =& sf_factoryGetObject('HTTP', 'WebRequest');
$page = $req->getValAsInt('page', 1);
$length = ($cms_mod['container']['cms:items_per_page'])?(int)$cms_mod['container']['cms:items_per_page']:15;
...
$pager =& sf_factoryGetObject('GUI', 'Pager');
$pager->setTotalItems(count($content[$cms_mod['container']['id']]));
$pager->setItemsPerPage($length);
$pager->setCurrentPage($page);
$pager->generate();
$search[] = '<cms:pager />';
$replace[] = $pager->getLinks();


Und fertig ist! Das einzige was mir nicht gefällt - glaub ich - ist dass ich einen neuen CMS-Tag gebaut habe: <cms:pager />, mit dem ich überall im Layout den Pager einfügen kann.

Jetzt fehlt noch:

- Konfiguration und Mehrsprachigkeit
- mod_rewrite unterstützen
- Paging auch im Backend

Tschüss
Tiggr

PS: Neue Version anbei, die - falls vorhanden - die schnellere Funktion array_slice von PHP (>= 5.0.2) nutzt.
Tiggr
Hiho nochmal!

Hab es mal mit MrList ausprobiert, da klappt es auch, und das schöne ist, ich mußte nur 2 Sachen machen:

- 2 Optionen in der Modul-Konfig zufügen
- <cms:pager /> im Layout einfügen

Der Speicherüberlauf ist damit auch weg...

Wenn ich mal darüber nachdenke, Sefrengo verbraucht an so Stelle auch viel Speicher. Der gesamte Seiteninhalt wird in $content gehalten, dann nochmal in $code, dann auch noch in $container_code und auch noch in $layout. 4mal ähnlicher Inhalt im Speicher! Oder seh ich da was falsch?

Tschüss
Tiggr
Tiggr
Hiho!

Backend-Konfiguration ist noch nicht ganz fertig, aber es funktioniert schon mal.

Klicken um den Anhang anzusehen


Hat jemand noch Interesse an dem Kram, oder ist das eine Insellösung von mir? Je nach dem würde ich jetzt weiter vorgehen. Für mich alleine reicht es so, wie es ist! ;-) Muß nurnoch irgendwie mod_rewrite reinhacken.

Wenns auch wer anders gebrauchen kann, dann müßte ich gründlicher vorgehen! Oder jemand der besser ist, sich des ganzen annehmen!

Tschüss
Tiggr
bkm
Ich frage mich nur => wozu der ganze Aufwand.
Wenn es in einem Modul gebraucht wird, kann man es doch auch dort unterbringen.
(s. Gästebuch oder Seitennavi.)


ZITAT(Tiggr @ Sun. 25. February 2007, 15:45) *
PS: Neue Version anbei, die - falls vorhanden - die schnellere Funktion array_slice von PHP (>= 5.0.2) nutzt.

array_slice gibt es doch auch schon unter PHP4
Tiggr
Hallo!
ZITAT(bkm @ Sun. 25. February 2007, 23:07) *
Ich frage mich nur => wozu der ganze Aufwand.
Wenn es in einem Modul gebraucht wird, kann man es doch auch dort unterbringen.
(s. Gästebuch oder Seitennavi.)


Genau das will ich ja vermeiden!

In diesem Fall kaut Sefrengo nämlich den gesamten Inhalt des sich im Container wiederholenden Moduls durch. Wenn man zum Beispiel mit ContentFlex oder MrList ein Blog mit 200 Einträgen hat, und pro Seite 5 davon anzeigt, dann holt Sefrengo alle 200 Einträge, hängt sie aneinander, und überläßt es jedem Eintrag für sich, zu entscheiden, ob er angezeigt werden möchte. Das ist nicht nur langsam, sondern kostet auch unheimlich Speicher! Bei MrList bis zum Zusammenbruch, das Modul klappt bei mir schon bei 32MB RAM für PHP im Apache weg! :-( Und ich hab da nur 52 Einträge drin. Das gibt dann 42.000 Zeilen Code, die Sefrengo da aufbaut, und abarbeitet. Ich hab mir den Code mal ausgeben lassen, und angesehen! 42.000 Zeilen Code, zweiundvierzigtausend! Und das um ein wenig HTML das schon formatiert vorliegt auszugeben.

Nach meiner Änderung sind es nur noch 5 Wiederholungen des Moduls im Code, statt 52! Weil Sefrengo das Paging übernimmt und weiß, was er braucht! Und auch bei 200 Beiträgen bleiben es 5! Ist noch nicht optimal, weil im $content-array liegt noch immer alles drin, aber zumindest durchläuft Sefrengo nicht mehr alles! Am besten wäre es, wenn im $content-array nur das läge, was gebraucht wird.

Darüber hinaus finde ich es etwas unschön, das die Seitennavi vom MrList anders aus sieht als die von FotoAlbum, weil die Module jeweils das Rad neu erfinden.

So etwas zentrales wie das Aufteilen auf Seiten sollte IMHO eigentlich einheitlich und zentral gelöst werden!

ZITAT
array_slice gibt es doch auch schon unter PHP4


OK, hab mich nicht genau genug ausgedrückt, ich meinte 'preserve_keys' bei der Funktion:

ZITAT
Beachten Sie, dass array_slice() nach Vorgabe numerische Schlüssel des Arrays zurücksetzt. Seit PHP 5.0.2 können Sie dieses Verhalten ändern, indem Sie preserve_keys auf TRUE setzen.


Tschüss
Tiggr
saschapi
klingt vernünftig, auch wenn ich bei der technischen umsetzung die Eselsmütze aufsetzten muss wink.gif
gunwalt
ZITAT(Tiggr @ Mon. 26. February 2007, 00:20) *
Darüber hinaus finde ich es etwas unschön, das die Seitennavi vom MrList anders aus sieht als die von FotoAlbum, weil die Module jeweils das Rad neu erfinden.

Wenn es um Standarisierungen geht, ist dies sicherlich ein guter Ansatz. Die unterschiedlichen Navis haben mich auch schon immer verwundert. Gibt es eigentlich Probleme mit den unterschiedlichen Navis, wenn sie ausversehen parallel arbeiten?
Sollte das nicht auf eine Arbeitserleichterung für Modulentwickler hinauslaufen?

@Tiggr: ich sehe, das du in deinem Beispiel Smartypants drinne. Nur eine Idee - keine Ahnung, ob das überhaupt geht - läßt sich Paging ähnlich als Plugin anlegen. Dann könnte jeder entscheiden, ob diese Funktion gewünscht wird.

@entwickler: Wie sieht eigentlich die Meinung der Entwickler zum diesem Thema aus?
feniweb
@tiggr

Finde das eine nötige lösung da SF auf einigen ausgelasteten SH Hostings teilweise schon recht langsame Seitenaufbaus haben, da begrüsst man jede Speichereinspahrung.

Einhaitliches erscheinungsbild ist sehr wichtig. Natürlich konnt man per CSS in den anderen Modulen fast alles anpassen.

tiggr weiter so. tongue.gif

Gruss
Tiggr
Hiho!

ZITAT(gunwalt @ Mon. 26. February 2007, 13:17) *
@Tiggr: [...] läßt sich Paging ähnlich als Plugin anlegen. Dann könnte jeder entscheiden, ob diese Funktion gewünscht wird.


Die Frage hab ich mir auch schon gestellt. Bezweifle das aber, immerhin läuft es auf ein überschreiben einiger wichtiger Systemfunktionen hinaus.

ZITAT
@entwickler: Wie sieht eigentlich die Meinung der Entwickler zum diesem Thema aus?


Wüßte ich auch ganz gern! ;-) Ich hoffe hier ja eine Anregung für Sefrengo zu geben. Wenn ich das nur für mich selber bastle, hab ich ja bei dem nächsten Update ein Problem! Gebt mir doch mal bitte eine sinnvolle Richtung vor!

Tiggr
bjoern
Die Optimierungen im Code, die Du im Core und im MrList gemacht hast, finde ich gut. Ich fände es schön, wenn Du daraus ein bereinigtes Modul (in Absprache mit amk - Originalautor vom Modul), bzw. einen Corepatch von der inc.generate_code.php machst und im Hack-/ Sonstigesforum postest. Wenn der Hack sich als stabil herausstellt kommt der auf jeden Fall in den Core.

Das Nav tag gefällt mir aber überhaupt nicht und werde ich nicht übernehmen. Gründe:
- Flexibele Anpassungen sind im $cfg_lang Array nicht gegeben. Es kann nur 1 Navset erstellt werden.
- Die Attributgesteuerten cms:tags geben (noch) keine Möglichkeiten zur flexible Gestaltung. Eine Konfiguration wäre wenn, dann hier vorzunehmen. Aus Gründen der Komplexität der Konfiguration halte ich das für nicht gut machbar.
- Die 1.4 ist für mich so gut wie im Kasten und für die 1.6 möchte ich den ganzen "prozeduralen Mist" aus diesem Bereich gerne in Objekte packen. Da halte ich es für wenig sinnvoll jetzt noch größere Baustellen aufzureißen.

Sinnvolle Richtung wäre: Den bereich in ein Objekt packen; dann die CMS- Tags erweitern, das diese auch einen Syntax wie
QUELLTEXT
<cms:mod type="nav">
  <spacer>|</spacer>
  <pagevar>page</pagevar>
  ...
</cms:mod>

verstehen und dann die Navigation machen. Da das aber ein enormer Aufwand ist, würde ich vorschlagen, diejenigen, welche eine Navigation benötigen, benutzen dazu erst einmal das entsprechende API Objekt. smile.gif
Tiggr
Hi Bjoern!

Ich muß leider gestehen, du hast mich jetzt abgehängt! ;-)

Erstmal was ich bisher verstanden habe, und da stimme ich dir erstmal zu: der nav-Tag war ein schneller Hack, weil mir nichts besseres eingefallen ist, um die Navi, die ich im Core erzeuge auszugeben. Ich muß also die Navigationserzeugung wieder in das Modul verlagern. Macht auch irgendwie mehr Sinn, wenn ich drüber nachdenke, aber halt einheitlich über eine API!

Ich denke mal über einen saubereren Weg nach, eigentlich muß MrList, also das Modul ja nur wissen, wieviele Elemente/Seiten es gibt, auf welcher Seite man gerade ist, ist ja kein großes Geheimnis mehr - wenn ich einen Namen für die Pagervariable in der URL irgendwo zentral vorgebe.

Das generelle Problem ist, das irgendwie der Core mit dem Modul reden muß, und auch umgekehrt...
  • Das Modul muß dem Core mitteilen, wie viele Elemente es pro Seite geben soll, und das der Core nur einen Teilbereich ausgeben soll. Das klappt schon, auch wenn ich nicht ganz glücklich mit den cms:irgendwas-Variablen bin.
  • Der Core muß dem Modul (oder umgekehrt?) mitteilen, auf welcher Unterseite es sich befindet. Momentan kratze ich diesen Wert aus dem Request, und geb den Namen der Request-Variable zentral vor, wenn das für dich ok ist, ich kann damit leben, kann ja ruhig sprachabhängig sein, wäre dann eine Spracheinstellung im Projekt. Hmmm, eigentlich sind das nur andere cms:irgendwas-Variablen! ;-)
  • Der Core muß dem Modul mitteilen, wieviele Seiten es insgesamt gibt... wie macht man das elegant? Hier hab ich noch keine Vorstellung! Hmmm, eigentlich sind das nur andere cms:irgendwas-Variablen! ;-)
Falls ich das hinbekommen - gib mal Tipps - dann stell ich das als Core-Hack vor mit einem einfachen Demomodul, und reden dann mit amk über MrList!

Tschüss
Tiggr
Tiggr
OK, je mehr ich drüber nachdenke, um so mehr denke ich, das kann klappen.

Ich mach mich morgen Abend mal dran!

Tschüss
Tiggr
Tiggr
Ok, war einfacher als Gedacht, nun übernimmt das Modul wieder die Darstellung des Pagers, und es sind nur wenig Fragen offen! :-) Aber die Fragen sind für mich zur Zeit zu schwierig!

Da gehts weiter: Paging-Unterstützung im Core

Tschüss
Tiggr
mistral
Hallo zusammen

Ich bin der Meinung, dass dieser Hack von Tiggr und die Idee dahinter genau das Gegenteil erreicht, als er es eigentlich möcht.
Mit dieser Modifikation wird zwar die Bearbeitung der Seite schneller, da dort nur die benötigten Daten aus der DB geladen werden. Aber für den Besucher wird der Seitenaufbau deutlich länger dauern, weil aus meiner Sicht der gesamte Caching-Mechanismus aus gehebelt wird.

Nach meinem Verständnis läuft das gesamte System so, dass ein gewisser Teil der Module nur beim ersten aufrufen nach einer Modifikation der Seiten ausgeführt werden. Diese Seite, welche aber noch php-Code beinhalten kann wird nun in der DB gespeichert (caching). Die Seite, welche in den meisten Fällen bereits alle Inhalte aus der DB besitzt, wird nun in einem zweiten Schritt noch einmal verarbeiten. In diesem zweiten Schritt wird nun beispielsweise beim ContenFlex und auch bei MrList entschieden welche Teile ausgegeben werden sollen und welche Teile nicht ausgegeben werden. Auch die Navigation innerhalb von MRList wird erst zu diesem Zeitpunkt erstellt. Das heisst aus meiner Sicht, das wenn weitere Besucher die Seite anschauen, egal um welche Unterseite es sich gerade handelt, es wird immer nur dieser php-Code der gecachten Seite abgearbeitet.
Als Beispiel wird beim Modul ContentFlex pro Wiederholung (Element) folgender PHP-Code erzeugt.
Einige Variablen in welchem der Inhalt und Konfiguartion übergeben werden und einer Zeile welche ein zusätzliche Datein inculdet.
Diese Datei ist genau aus dem Grund entstanden, damit die Funktion welche die Navigation erstellt nicht x-mal in der decachten Datei stehen muss.
In dieser Datei wird nun für jedes Element zwischen 10 und 150 Zeilen Code interpretiert. Dabei sind es für alle Element die nicht sichtbar sind 10 Zeilen und für die Wiederholung welche die Navigation erzeugt und auch noch ein umschliessendes-Template verwendet 150 Zeilen.

Mit dem Hack von Tiggr wir jetzt aber bei jedem aufrufen der Seite der Inhalt komplett neu aus allen Einträgen die Sichtbar sind aus der DB zusammengesetzt und anschliessend in einem zweiten Schritt wie bisher nochmals verarbeitet. Wenn ich die Daten von Tiggr korrekt sind werden pro Wiederholung über 1000 Zeilen Code dabei sind aber aus meiner Sicht die aufrufe von Core-Funktionen noch nicht enthalten. Wenn ich jetzt mit einer Seite mit 5 von 100 angezeigten Einträge rechen sind das vorhandenen Sytem ca. 1500 Zeilen PHP-Code für das Modul und eine SQL-Anfrage für die Ausgabe eines Besuchers. Mit dem Hack von Tiggr sind es dann aber 5000 Zeilen PHP-Code plus mindestens 50-300-SQL abfragen. Aus meiner Sicht ist das also kein Beschleunigung des Systems sondern ein Bremse.
Für das Bearbeiten der Seite sieht es natürlich ganz anders aus, das ist mir klar.

Aus meiner Sicht muss dafür gesorgt werden das in den Modulen redundanter Code möglichst nur einmal vorhanden ist und optimaler sogar in eine separate Datei ausgelagert wird. Das heisst in diesem konkreten Fall dass der Code welcher nur bei der letzten Wiederholung benötigt wird in eine separate Datei ausgelagert wird. Wenn ich das Modul MrList richtig interpretiere sind dieser Bereich welcher nur für die letzte Wiederholung benötigt wird über 600 Zeilen. Also sollte das Auslagern dieser 600 Zeilen dazuführen das beim Beispiel von Tiggr von den 42000-Zeilen ca 30000-Zeilen eingespart werden könnten.

Gruss
Mistral
Tiggr
Hiho!

Das mit dem Caching ist ein echtes Argument. Ich kann nur sagen, gefühlt läuft es so gehackt schneller, aber du hast sicher recht, dass man da Caching unterläuft!

Kann man noch was retten bei meinem Hack? Weil die Speicherersparnis ist wirklich signifikant! Und darum ging es mir ja erstmal in erster Linie! Ich finde es einfach ineffektiv immer den gesamten Content in arrays zu halten, und das auch noch mehrfach!

ZITAT
und einer Zeile welche ein zusätzliche Datein inculdet.
Die Datei wird dann aber doch gegebenenfalls auch x-mal interpretiert!

Kann man das Caching feiner steuern? Zum Beispiel bei Seiten mit Paging auch noch über eine Requestvariable?

Ich glaub immer noch, das mein Hack nicht grundsätzlich falsch ist, aber er mag Probleme haben... Wahrscheinlich bekämpfe ich nur ein Problem mit einem anderen... ;-)

Ach ja:

ZITAT
50-300-SQL


Sind das wirklich so viele???? Dann wäre hier auch noch was zu tun! Auch wenn das die wenigsten wissen/glauben: Datenbanken sind langsam! Je weniger SQL-Queries um so besser!

So gesehen wäre es auch sinnvoll, den Cache nicht in der DB sonder im Filesystem zu haben!

Tschüss
Tiggr
mistral
ZITAT(Tiggr @ Tue. 27. February 2007, 10:04) *
Das mit dem Caching ist ein echtes Argument. Ich kann nur sagen, gefühlt läuft es so gehackt schneller, aber du hast sicher recht, dass man da Caching unterläuft!

Hast du die Geschwindigkeit als Besucher verglichen (nicht im Backend eingeloggt und die Seite mehrfach anzeigen lassen). Wie ich geschrieben habe wird dein Hack dazuführen, das es im Backend schneller läuft, aber die Geschwindigkeit für den Besucher ist ja wichtiger.

ZITAT(Tiggr @ Tue. 27. February 2007, 10:04) *
Die Datei wird dann aber doch gegebenenfalls auch x-mal interpretiert!

Erstens nein, da die Datei nur dann inculdet werden müsste wenn wirklich die letzte Wiederholung abgearbeitet wird und zweitens würde das interpretiern nur marginale Zeit benötigen.

ZITAT(Tiggr @ Tue. 27. February 2007, 10:04) *
Ach ja:
Sind das wirklich so viele???? Dann wäre hier auch noch was zu tun! Auch wenn das die wenigsten wissen/glauben: Datenbanken sind langsam! Je weniger SQL-Queries um so besser!

Es sind so viele da für jeden cms-Tag ein SQL ausgeführt wird und der Caching ja nicht mehr funktioniert.
Die Anzahl SQL kann mit der hier beschriebenen Variante für MrList deutlich gesenkt werden und hat, wie in dem Beitrag geschrieben, beim ContenFlex zu einer Geschwindigkeitssteigerung im Backend von Faktor 4 ergeben:
Beitrag

Gruss
Mistral
Tiggr
QUELLTEXT
Die Anzahl SQL kann mit der hier beschriebenen Variante für MrList deutlich gesenkt werden und hat, wie in dem Beitrag geschrieben, beim ContenFlex zu einer Geschwindigkeitssteigerung im Backend von Faktor 4 ergeben


Jau, das hab ich schon in meiner Variante von MrList umgesetzt, das war ja nur Fleißarbeit! ;-)

Hat auch zur Geschwindigkeitssteigerung geführt! Zwar nicht Faktor 4, aber spürbar!


Jetzt nochmal zum Hack: Da ging es mir ja darum Speicher zu sparen, generell und nicht Modulabhängig. Ich bin auch trotz des Caching-Arguments kein Fan davon alle Containerinhalte einzulesen, alle zu bearbeiten und damit den Speicher zu füllen. Vorallem auch noch mehrmals, erstmal im $content, dann im $container_content, dann im $output!

Ich denke eher, hier sollte optimiert werden, und dann muß das Caching auch noch optimiert werden!

Tiggr
Tiggr
Aua, ich setz mir gerade die Eselsmütze auf! Ich hatte mal zum testen den Frontendcache abgestellt. Ist er aktiviert, kann man munder in der Navi klicken was man will, es wird immer die Seite 1 angezeigt, weil die im Cache liegt und Sefrengo ja nicht merkt, das sich was ändert, aber ich hab da mal ne Idee! Ich meld mich wieder, hoffentlich mit einem funktionierendem Cache!

Tiggr
Tiggr
So, hab mich gerade geschlagen gegeben! Das war der falsche Weg, zumindest für einen schnellen Hack! :-(

Mehr dazu warum da: Ich geb auf...

Tschüss
Tiggr

PS: Macht mal bitte ein Mod hier dicht, damit wir nicht an zwei Stellen drüber sprechen? Danke!
Dieses ist eine vereinfachte Darstellung unseres Foreninhaltes. Um die detaillierte Vollansicht mit Formatierung und Bildern zu betrachten, bitte hier klicken.
Invision Power Board © 2001-2024 Invision Power Services, Inc.