Hallo zusammen.
Es gibt natürlich unzählige Ansätze. Eine Variante wäre, die Remote-Daten als lokale Domäne abzubilden und per Scheduler einen Import zu bauen. Wenn z.B. ein beliebiges JSON- oder XML-Format verwendet wird um Daten bereitzustellen die in TYPO3 als News angezeigt werden sollen bietet es sich ja an, alle paar Minuten die Daten remote abzufragen und in lokale News-Records zu überführen. Der Vorteil daran ist natürlich, dass man keinen gesonderten Renderingprozess für diese News konfigurieren muss, wenn es ohnehin schon anderweitige, lokale News gibt. Auch wenn man in eine lokale Suche die Remote-Daten integrieren möchte bietet sich dieser Schritt an. Wenn man erst einen Import von einer Remote-API in lokale Datensätze durchführt, kann im Folgeschritt z.B. ein Solr-Indexing-Task die Daten in den Solr schaufeln und sie sind im Frontend über die Suche verfügbar. Dabei sollte der Import natürlich über den TYPO3 DataHandler durchgeführt werden, weil das die zentrale Stelle ist, die sowohl eine für Redakteure nachvollziehbare History erzeugt also auch der API-Call, an den sich wiederum Record-Indexer wie eben Solr hängen um innerhalb von TYPO3 über Datenänderungen informiert zu werden. Auch was Caching innerhalb einer TYPO3-Seite betrifft (Cache-Tags im Caching-Framework) ist die Verwendung des DataHandler dringend angeranten. Eine weitere Möglichkeit ist ein Runtime-Cache. Der API-Aufruf ist sicherlich in irgendeiner Form ein HTTP GET-Request. Das heißt hier gibt es eine URL aus der sich ein Cache-Identifier ableiten lässt sowie einen Response-Body der der Cache-Content sein kann. Hier rate ich dringend dazu, nicht irgendeine selbst erfundene Datenbankstruktur zu verwenden, sondern das Caching-Framework. Für die Speicherung der Daten gibt es unterschiedliche Backends, nämlich u.a. dateibasiert, datenbankbasiert, memcache oder redis. Je nach Bedarf und Verfügbarkeit. Dem Konsumenten des Caches gegenüber stellt man die Daten dan entweder über das Variable-Frontend zur Verfügung (z.B. wenn es sich um Array oder Objekte handelt) oder über das String-Frontend (wenn der Konsument den Text-Body bekommen soll). Wenn der Cache richtig konfiguriert ist, lässt er sich über die „Clear Cache“-Buttons im Backend rechts oben ganz einfach leeren, wodurch das auch von Redakteuren bedient werden kann. Oder auch ein „Clear all Caches“ wie man es ja vermutlich im Rahmen jedes Code-Deployments anstößt (Stichwort CLI-API!) nimmt das Caching-Framework, man muss sich also nicht selbst darum kümmern. In beiden Fällen ist natürlich kein Weg beschrieben, wie Inhaltsänderungen des Providers an TYPO3 kommuniziert werden können. Das heißt, dass Du Dir eine Cache-Lifetime ausdenken musst die im Zweifelsfall zu kurz oder zu lang ist. Eine Lifetime von wenigen Minuten könnte dafür sorgen, dass Du trotzdem an ein anbieterseitiges Request-Limit stößt. Eine Lifetime von mehreren Minuten dagegen sorgt immer für panische Anrufe von Redakteuren, warum die Inhaltsänderung nicht sofort auch in TYPO3 sichtbar ist. Hier sollte es im Idealfall Empfehlungen des API-Providers geben an die man sich halten kann. Dann lassen sich diese Empfehlungen dem Kunden kommunizieren und die panischen Redakteure können mit Fakten beruhigt werden. Wenn es sich um einen HTTP GET-Request handelt der seinerseits Cache-Header enthält, könnte man sich auch an die halten. Wenn z.B. ein „Cache-Control: Max-Age“ kommt kann ich ausrechnen wie lange ich diesen Wert cachen darf. Wenn ein „Cache-Control: Private“ kommt brauch ich mit dem Caching gar nicht anfangen. Mir ist hierzu aber nichts bekannt das das durch eine Library abdecken würde. Wenn das im Rahmen Deines Projekts entsteht schreit das also nach einer Veröffentlichung. Wenn lediglich innerhalb eines einzigen TYPO3-Prozesses ein Request gecacht werden soll, würde ich trotzdem das Caching-Framework verwenden. Gemeint ist, wenn der gleiche GET-Request z.B. durch ViewHelper mehrmals vom gleichen TYPO3-Prozess abgeschickt wird. Man könnte zwar auf den ersten Blick auf die Idee kommen, einfach eine Singleton-Klasse zu schreiben die den Request unterdrückt, wenn für die URL bereits eine Response in einer Instanzvariable steht. Das wirft man allerdings komplett weg, wenn man das Caching über mehrere Prozesse ausdehnen will. Besser man verwendet gleich das Caching-Framework und stellt als Backend erst mal das „TransientMemoryBackend“ ein. Das ist nur innerhalb eines PHP-Prozesses gültig, d.h. der nächste Click startet wieder mit einem leeren Backend und macht einen neuen HTTP-Request. Wenn man allerdings später das Caching über mehrere Prozesse strecken möchte, gibt man einfach ein anderes Backend über die LocalConfiguration oder EnvironmentConfiguration an, ohne seinen PHP-Code anfassen zu müssen. Auch lassen sich so z.B. ein Stagingserver mit TransientMemoryBackend (weil der eh keine nennenswerte Last aber dafür ungeduldige Spielkinder als Redakteure hat) und ein Produktivserver mit MamcacheBackend (weil der unter hoher Last fährt und es ohnehin nicht so wichtig ist, ob Kunden nun fünf Minuten früher oder später an die aktualisierten Daten kommen) betreiben, einfach, indem über die individuellen EnvironmentConfiguration.php-Dateien unterschiedliche Backends oder unterschiedliche Lifetimes konfiguriert sind. In allen Fällen mit Runtime-Cache (egal ob mit Caching-Framework oder selbstgebastelt) muss das aber natürlich auch in irgendeiner Form mit dem Caching der TYPO3-Seite selbst synchronisiert werden. Es bringt überhaupt nichts, wenn mein Caching-Framework die Daten nach fünf Minuten wegwirft, aber mein TYPO3 Page-Cache einen Tag lang die gleiche Seite ausliefert. Wie das jetzt am sinnvollsten geht hängt wiederum vom Anwendungsfall ab. Und „No-Cache“ ist natürlich keine Option. 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
