Hallo zusammen.
Matthias, Du bist am Problem vorbei. Die Anforderung ist nicht, Inline-JS in
eine Datei zu überführen.
Das Problem ist, dass der gegebene Beispielcode entweder kein gültiges Fluid
ist oder aber der Fluid-Parser damit so seine Schwierigkeiten hat. Je nach
Betrachtungsweise. Und in dieser Hinsicht spielt es keine Rolle, ob der
Inline-JS-Code dynamisch zur Laufzeit in Dateien gepackt wird oder im
HTML-Output steht. In beiden Fällen läuft er entweder durch den Fluid-Parser
und macht Probleme oder er läuft nicht durch den Fluid-Parser und hat dann
leider auch keine Variablen.
Einerseits bin ich der Überzeugung, dass Inline-JS grundsätzlich wegoptimiert
gehört. Die Auslagerung in Dateien – statische, nicht zur Laufzeit erzeugte –
erlaubt dem Browser dann sinnvolles Caching und spätestens beim zweiten Aufruf
einer Seite mit identischem Code hat sich die statische Datei gegenüber dem
Inline-JS sowohl was den Traffic als auch die Latenz betrifft bezahlt gemacht.
Hier statische Dateien zu nehmen und das nicht zur Laufzeit zu machen ist
wichtig, damit sich die Datei nicht spontan ändert (mtime und content) und
immer exakt die gleiche Datei auf allen Seiten eingebunden wird. Nur so muss
der Browser die Datei nicht bei jedem Seitenrequest erneut vom Server holen.
Dynamisch beim Seitenaufbau JS-Dateien zu produzieren dern Inhalt sich aber von
Seite zu Seite unterscheidet sorgt dafür, dass der Browser bei jedem
Seitenrequest eine andere Datei braucht, und dann ist gegenüber dem Inline-JS
nichts mehr gewonnen.
Anderseits könnte man vielleicht mit einer Kombination aus RawViewHelper und
ReplaceViewHelper arbeiten. Der RawViewHelper soll dafür sorgen, dass das JS
überhaupt nicht von Fluid beachtet wird sondern als Zeichenkette behandelt. Und
der ReplaceViewHelper drum herum soll dann einzelne ausgewählte Platzhalter
ersetzen. Natürlich beschränkt das den Inhalt des JS-Codes auf pure
Platzhalter, die Verwendung von ViewHelpern (ich denke insbesondere an if oder
switch/case) ist dann nicht möglich. Aber das muss es ja vielleicht auch gar
nicht.
Beste Grüße,
Am 09.02.17, 12:41 schrieb "typo3-german-boun...@lists.typo3.org im Auftrag von
Matthias Eberlein" <typo3-german-boun...@lists.typo3.org im Auftrag von
skydivem...@gmail.com>:
Hier der Link zum viewHelper
https://github.com/mhirdes/go_maps_ext/blob/master/Classes/ViewHelpers/ScriptViewHelper.php
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
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
