@Hallo Stefan
Das mit den Klassen war nur ein einfache Beispiel. Selbst im dynamischen
Fall ist das direkte Einsetzen in Styles sinnvoller.
@Hallo Matthias,
danke für den Tipp. Aber wie Stephan nachfolgen schrieb, möchte ich
etwas in das JavaScript hineinparsen.
@Hallo Stephan,
danke für die Richtig-Stellung. Genau das nicht funktionierende Parsen
im Fluid ist mein Problem. Deinen Glaubenssatz, dass inline-JavaScript
grundsätzlich in statische Dateien gehört, würde ich im Grundsatz sofort
mit unterschreDiben. Das Paradigma von der anzustrebenden
Wiederverwendbarkeit von Code ist wichtig.
Aber zu jedem Glaubenssatz gibt es Ausnahmen; nämlich immer dann, wenn
dessen Prämisse nicht gegeben ist. Bei automatisierten Funktionstest ist
die Prämisse zum Beispiel nicht gegeben.
Wenn ich die Funktionalität des JavaScripts der Website im Live-Betrieb
mit Hilfe von automatisierten Tests via Jasmine absichern möchte, muss
ich die javaScript-Tests dynamisch mit echten Daten dynamisch
parametrisieren können. Unter anderem dafür brauche ich den Viewhelper
und Inline-Javascript-Code.
Ich werde ihn wohl selbst programmieren müssen. *Grummel* .
Mit besten Grüßen
Dieter
P.S. Die Raw-&Replace-Viewhelper-Variante finde ich unscharmant, weil
ich dann auf Fluidvariablen beschränkt bin. Was mache ich, wenn ich
manche TestDaten per cObject-Viewhelper bestimmen möchte?
Am 09.02.2017 um 13:10 schrieb Stephan Schuler:
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
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
