AJAX im TYPO3-Frontend
AJAX ist was feines für den Besucher, alles fühlt sich schneller und flüssiger an. Für den Entwickler kann es manchmal aber eher mühsam sein. Man braucht die Javascript-Funktionalität und die Server-Funktionalität. Hier im Artikel will ich kurz anreißen, wie die Server-Funktionalität elegant in TYPO3 integriert und die Vorteile, die TYPO3 hier mitbringt, genutzt wird.
AJAX mit eID-Machanismus
Mit dem integrierten eID-Mechanismus von TYPO3 ist es möglich, eigene PHP-Scripte ohne großen Overhead aufzurufen. Instanziert wird dabei nur alles, was man unbedingt braucht oder will. Der Nachteil dabei ist jedoch, das viele interne TYPO3-Bordmittel nicht zur Verfügung stehen. So müssen z.B. für die Spracherkennung oder wenn TypoScript-Bedingungen beachtet werden sollen, komplizierte Workarounds integriert werden. Dadurch wird das anfänglich schlanke Script schnell aufgebläht und unübersichtlich. Und im schlimmsten Fall entstehen dadurch sogar Sicherheitslücken, beispielsweise dann wenn es dem Benutzer Möglich ist, über das AJAX-Backends Daten abzufragen für die er in seiner Benutzergruppe ggf. gar keine Berechtigung haben sollte.
Der eID-Mechanismus ist also meiner Meinung nach für einfache und unkomplizierte Abfragen geeignet. Kommen aber irgendwelche Bedingungen ins Spiel, von denen die Abfrage abhängig sein sollte, empfehle ich eine andere Herangehensweise.
AJAX mit eigenem Seiten-Typ
Wer schon einmal ein TYPO3-Projekt erstellt hat, kennt die Seiten-Typen vermutlich von der Druckansicht. Oftmals wird mit typeNum=98 ein Page-Objekt für die Druckansicht definiert, dass sich dann mit einem angehängten Parameter (z.B. http://www.example.com/index.php?id=1&type=98) aufrufen lässt und eine völlig andere Ansicht der Webseite offenbart.
Genau dieses Feature lässt sich auch nutzen, um ein z.B. ein eigenes Extension-Plugin mit einem definierten Seiten-Typ zu verknüpfen. Hier im Beispiel erzeugen wir mit myajax ein neues Objekt vom Typ PAGE. Mit typeNum = 789 wird dann eine alternative Typ-Nummer vergeben. Und nach ein paar Beispielkonfigurationen wird dann noch das Plugin als einziger Content eingebunden.
Unser Plugin ist dann direkt über http://www.example.de/index.php?id=23&L=1&type=789 erreichbar und liefert automatisch die korrekten Ergebnisse, abhänig vom gesetzten Sprachparameter, der gewählten Seite und den aktuellen Berechtigungen des Benutzers. (Die Parameter id und L im Beispiellink sind natürlich variabel und hier nur als Beispiel gesetzt.)
# prepare alternative page type
myajax = PAGE
myajax.typeNum = 789
myajax.config {
disableAllHeaderCode = 1
additionalHeaders = Cache-Control: no-cache, must-revalidate, max-age=0|Expires: Mon, 2 Jan 2006 01:00:00 GMT|Pragma: no-cache
xhtml_cleaning = 0
}
# register plugin directly as page content
myajax.10 < plugin.user_myajaxplugin_pi1
Der Nachteil dieser Lösung ist, dass bei jeder Anfrage der komplette standardmäßige TYPO3-Overhead mitgeführt wird. Es ist also von Haus aus eher die etwas langsamere Variante im Vergleich zur oben genannten eID-Lösung.
Der enorme Vorteil hingegen ist jedoch, dass sich die AJAX-Serverfunktionalität exakt gleich zur normalen Seite verhält. Alle Spracheinstellungen, die Berechtigungen für irgendwelche Seiten, TypoScript-Conditions, etc. haben auch direkten Einfluss auf die AJAX-Funktionalität und können von einem Angreifer nicht mit einfachen Parameter-Änderungen in der Adresse ausgehebelt werden.
Fazit
Grundsätzlich würde ich keine der beiden Varianten als “besser” oder “schlechter” bezeichnen. Für einfache AJAX-Abfragen ohne Einschränkungen wie z.B. Sprache, Berechtigung, etc. würde ich die kleinere Schlankere Variante mit dem eID-Mechanismus wählen. Sobald aber Inhalte nur für eine bestimmte Besuchergruppe sichtbar sein sollen, oder in verschiedenen Sprachen verfügbar, rate ich zweifellos zur Variante mit dem eigenen Seiten-Typ.
