Hallo Fabian. So funktioniert das Caching-Framework nicht. Erstens machst Du einen Großteil dessen was das CF für Dich tun soll selbst und zweitens läufst Du Gefahr, irgendwann für eine gewisse Zeit keine Daten zu haben.
https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/CachingFramework/FrontendsBackends/Index.html Du willst primär FrontendInterface::has(), FrontendInterface::get() und FrontendInterface::remove() aufrufen. Jeweils ist Dein Cache-Content ein Array aus allen Objekten die für ein Plugin relevant sind. Der Cache im CF hat eine Lifetime. Wenn der Scheduler nicht rechtzeitig läuft – sagen wir, weil der SOAP-Server hängt, PHP in ein Timeout läuft und die Daten eben einfach nicht gespeichert werden – ist der Cache-Inhalt weg und Dein Plugin fliegt auf die Nase. Die einzige Möglichkeit die Du hast: Die Lifetime so hoch zu setzen, dass das nicht passiert. Dann hast Du das Lifetime-Feature ausgehebelt und baust es im Prinzip durch den Scheduler nach. Der zweite Punkt: Du hast doppelte Daten. Wenn Du zwei Plugins mit unterschiedlicher Konfiguration hast, bekommen Die nach Deiner Vorstellung unterschiedliche Cache-Identifier. Wenn sich die Daten dieser beiden Plugins überschneiden, hast Du die Objekte in beiden Caches unabhängig voneinander. Wenn Du es jetzt durch einen laggy SOAP-Server o.ä. schaffst, dass der Scheduler-Run für das eine Plugin klappt aber der für das zweite abbricht, zeigt Deine Seite vielleicht in den beiden Plugins unterschiedliche Informationen für das gleiche SOAP-Objekt an. Dann kommt der Flush. Es erfordert sehr viel Disziplin, wirklich nie und unter keinen Umständen ein „Clear all caches“ durchzuführen. Dass der Button aus dem rechten oberen Backend-Bereich verschwunden ist hat da schon sehr geholfen. Trotzdem sehe ich immer noch „Admin-Redakteure“, die jetzt übers Install-Tool „Clear all Caches“ drücken, wenn im Frontend mal was hängt. Bei mir passiert das „Clear all Caches“ immer, wenn ich einen neuen Code-Stand deploye. Je nach Projekt zwischen einmal die Woche und mehrmals täglich. Lässt sich nicht ändern, wenn neuer PHP-Code kommt sind Caches tödlich. Und was passiert, wenn man „Clear all Caches“ drückt? Natürlich wird das CF geleert. Dein Frontend hat erst mal keine Daten und darf auf den nächsten Scheduler-Run warten, im schlimmsten Fall dauert es dann eine Stunde, bis die Tabellen im Frontend wieder Daten bekommen. Du möchtest lokale Datenhaltung im CF simulieren. Das CF ist aber keinesfalls für lokale Datenhaltung gedacht. Leg ins CF nur solche Daten, die Du wirklich zu jeder Zeit rekonstruieren kannst. Und gestalte Deinen eigenen PHP-Code so, dass nichts davon abhängt, dass die Daten im CF liegen. Wenn Du willst, bau Dir ein Service-Objekt das Du „ServiceObject::getDataByConfig($config)“ fragst. Dieser Aufruf darf die Daten aus dem CF nehmen wenn sie drin sind, wenn nicht muss er sie vom SOAP-Server holen, ins CF legen und dann zurückgeben. Für den Aufrufer dieser Methode muss vollkommen transparent sein, ob der Service die Daten aus dem Cache hat oder live abgeholt hat. Nur so lässt sich das CF verwenden ohne dass Du früher oder später auf Probleme stößt. Genau das ist dann die Stelle, die das Frontend blockiert, wenn der SOAP-Server lahm ist. Mein Vorschlag bezieht sich *nicht* auf das CF. Bau ein Extbase Domain Model mit Domain-Objekten, sinnvollem Datenbank-Layout für Dein Model und einem Repository, das Du im Plugin entsprechend Deinen Anforderungen fragen kannst. Der Scheduler füllt die Datenbank asynchron. Ich würde den Scheduler nicht über Extbase sondern über den DataHandler mit der Datenbank reden lassen, aber das ist Implementierungsdetail. Diese Daten siehst Du dann auch im TYPO3 Backend. Wenn Du möchtest, dass Deine Redakteure sie nicht bearbeiten können, verweiger ihnen entsprechende Berechtigungen. Sicherlich gibt es auch in dieser Ausprägung noch den ein oder anderen Anwendungsfall für das CF, aber bitte ausschließlich im Frontend und nicht, wenn es um die Synchronisation der Daten zwischen SOAP-Request und TYPO3-Datenbank geht. Beste Grüße, Stephan Schuler Web-Entwickler | netlogix Web Solutions Telefon: +49 (911) 539909 - 0 E-Mail: stephan.schu...@netlogix.de Web: websolutions.netlogix.de ---------------------------- Neu: Wir sind Amazon Web Services Partner. Mehr erfahren: https://websolutions.netlogix.de/technologie/amazon-web-services-aws ---------------------------- netlogix GmbH & Co. KG IT-Services | IT-Training | Web Solutions Neuwieder Straße 10 | 90411 Nürnberg Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99 E-Mail: i...@netlogix.de | Web: http://www.netlogix.de netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338) Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634) Umsatzsteuer-Identifikationsnummer: DE 233472254 Geschäftsführer: Matthias Schmidt _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
