Paging als Sefrengo-Funktion, <<|< 1|2|3| [4] |5|6 >|>> |
Willkommen, Gast ( Anmelden | Registrierung ) [ Hilfe | Mitglieder | Suche ]
Paging als Sefrengo-Funktion, <<|< 1|2|3| [4] |5|6 >|>> |
Sat. 24. February 2007, 23:17
Beitrag
#1
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 386 Mitglied seit: 12.07.2006 Mitglieds-Nr.: 136 |
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:
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!
Angehängte Datei(en)
-------------------- @bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo @bout LARP: LARP-Welt - CakePHP @bout Kites: Rodgauer Workshop - Contao |
|
|
Guest_bkm_* |
Sun. 25. February 2007, 00:33
Beitrag
#2
|
Guests |
Ist nicht eine Art der Seitenschaltung (-navigation) schon in der GUI =>Page (API)
sf_factoryGetObject('GUI', 'Pager'); enthalten ? |
|
|
Sun. 25. February 2007, 14:10
Beitrag
#3
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 386 Mitglied seit: 12.07.2006 Mitglieds-Nr.: 136 |
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 -------------------- @bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo @bout LARP: LARP-Welt - CakePHP @bout Kites: Rodgauer Workshop - Contao |
|
|
Sun. 25. February 2007, 14:50
Beitrag
#4
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 386 Mitglied seit: 12.07.2006 Mitglieds-Nr.: 136 |
Nochmal Hallo!
Stimmt, hast recht, gibt in der GUI auch ein Pager-Objekt, gleich mal damit rumspielen! Tiggr -------------------- @bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo @bout LARP: LARP-Welt - CakePHP @bout Kites: Rodgauer Workshop - Contao |
|
|
Sun. 25. February 2007, 15:45
Beitrag
#5
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 386 Mitglied seit: 12.07.2006 Mitglieds-Nr.: 136 |
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. Der Beitrag wurde von Tiggr bearbeitet: Sun. 25. February 2007, 19:34
Angehängte Datei(en)
-------------------- @bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo @bout LARP: LARP-Welt - CakePHP @bout Kites: Rodgauer Workshop - Contao |
|
|
Sun. 25. February 2007, 16:17
Beitrag
#6
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 386 Mitglied seit: 12.07.2006 Mitglieds-Nr.: 136 |
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 -------------------- @bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo @bout LARP: LARP-Welt - CakePHP @bout Kites: Rodgauer Workshop - Contao |
|
|
Sun. 25. February 2007, 20:54
Beitrag
#7
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 386 Mitglied seit: 12.07.2006 Mitglieds-Nr.: 136 |
Hiho!
Backend-Konfiguration ist noch nicht ganz fertig, aber es funktioniert schon mal. 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 Der Beitrag wurde von Tiggr bearbeitet: Sun. 25. February 2007, 20:58 -------------------- @bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo @bout LARP: LARP-Welt - CakePHP @bout Kites: Rodgauer Workshop - Contao |
|
|
Guest_bkm_* |
Sun. 25. February 2007, 23:07
Beitrag
#8
|
Guests |
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.) 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 Der Beitrag wurde von bkm bearbeitet: Sun. 25. February 2007, 23:25 |
|
|
Mon. 26. February 2007, 00:20
Beitrag
#9
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 386 Mitglied seit: 12.07.2006 Mitglieds-Nr.: 136 |
Hallo!
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 Der Beitrag wurde von Tiggr bearbeitet: Mon. 26. February 2007, 00:42 -------------------- @bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo @bout LARP: LARP-Welt - CakePHP @bout Kites: Rodgauer Workshop - Contao |
|
|
Mon. 26. February 2007, 08:35
Beitrag
#10
|
|
Advanced Member Gruppe: Moderators Beiträge: 911 Mitglied seit: 26.06.2006 Wohnort: Essen; Ruhrgebiet Mitglieds-Nr.: 4 |
klingt vernünftig, auch wenn ich bei der technischen umsetzung die Eselsmütze aufsetzten muss
-------------------- |
|
|
Mon. 26. February 2007, 13:17
Beitrag
#11
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 1.126 Mitglied seit: 27.06.2006 Mitglieds-Nr.: 7 |
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? -------------------- ------
Ich gehe spazieren durch Gelsenkirchen |
|
|
Mon. 26. February 2007, 13:31
Beitrag
#12
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 627 Mitglied seit: 30.06.2006 Mitglieds-Nr.: 25 |
@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. Gruss -------------------- feniweb
_____________________________________________________________________________ Wer kämpft, kann verlieren. Wer nicht kämpft, hat schon verloren. (Bertolt Brecht) |
|
|
Mon. 26. February 2007, 14:58
Beitrag
#13
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 386 Mitglied seit: 12.07.2006 Mitglieds-Nr.: 136 |
Hiho!
@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 -------------------- @bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo @bout LARP: LARP-Welt - CakePHP @bout Kites: Rodgauer Workshop - Contao |
|
|
Mon. 26. February 2007, 21:16
Beitrag
#14
|
|
Administrator Gruppe: Members Beiträge: 1.092 Mitglied seit: 16.06.2006 Wohnort: Köln Mitglieds-Nr.: 1 |
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. -------------------- Es wird, es wird...
|
|
|
Mon. 26. February 2007, 21:50
Beitrag
#15
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 386 Mitglied seit: 12.07.2006 Mitglieds-Nr.: 136 |
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...
Tschüss Tiggr Der Beitrag wurde von Tiggr bearbeitet: Mon. 26. February 2007, 21:53 -------------------- @bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo @bout LARP: LARP-Welt - CakePHP @bout Kites: Rodgauer Workshop - Contao |
|
|
Mon. 26. February 2007, 21:54
Beitrag
#16
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 386 Mitglied seit: 12.07.2006 Mitglieds-Nr.: 136 |
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 -------------------- @bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo @bout LARP: LARP-Welt - CakePHP @bout Kites: Rodgauer Workshop - Contao |
|
|
Mon. 26. February 2007, 22:59
Beitrag
#17
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 386 Mitglied seit: 12.07.2006 Mitglieds-Nr.: 136 |
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 Der Beitrag wurde von Tiggr bearbeitet: Mon. 26. February 2007, 23:01 -------------------- @bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo @bout LARP: LARP-Welt - CakePHP @bout Kites: Rodgauer Workshop - Contao |
|
|
Tue. 27. February 2007, 00:02
Beitrag
#18
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 343 Mitglied seit: 26.06.2006 Wohnort: CH Mitglieds-Nr.: 5 |
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 -------------------- So einfach wie möglich, aber nicht einfacher!
(Albert Einstein) |
|
|
Tue. 27. February 2007, 10:04
Beitrag
#19
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 386 Mitglied seit: 12.07.2006 Mitglieds-Nr.: 136 |
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 Der Beitrag wurde von Tiggr bearbeitet: Tue. 27. February 2007, 10:07 -------------------- @bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo @bout LARP: LARP-Welt - CakePHP @bout Kites: Rodgauer Workshop - Contao |
|
|
Tue. 27. February 2007, 11:28
Beitrag
#20
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 343 Mitglied seit: 26.06.2006 Wohnort: CH Mitglieds-Nr.: 5 |
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. 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. 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 -------------------- So einfach wie möglich, aber nicht einfacher!
(Albert Einstein) |
|
|
Vereinfachte Darstellung | Aktuelles Datum: 23.9.24 - 15:01 |