[TYPO3-german] gesucht: Viewhelper um Fluidvariablen in Inline-JavaScript einbauen zu können

[Dr. Dieter Porth]

Hallo Stefan ,

danke für den Tipp.


Am 10.02.2017 um 10:16 schrieb Stefan Padberg:
> Am 09.02.2017 um 09:59 schrieb Dieter Porth:
>> Liebe Liste,
>> Ich brauche zur Scopisierung von JavaScript-Funktionen in
>> TYPO3-Templates parametrisierten Inline-Code. Hier ein einfaches Beispiel:
>> .. $().ready( function () {
>> ..... $('#{idOfHeadline}').css('color','{color}');
>> .. });
>>
>> Leider mag TYPO3 solche Konstrukte überhaupt nicht.. Ich suche  als
>> Work-Araound einen Viewhelper, der im JavaScript alle Fluid-Ausdrücke
>> interpretiert, wenn zum Berispiel die Fluid-Ausdrücke statt der Spitzzen
>> Klammern durch spitze Doppelklamern "«" und "»"  eingeschlossen sind
>> Mein Wunschcode könnte gern zum Beispiel so aussehen.
>>
>> .. <x:fluidbrackets start="«" end="»">
>> ..... $().ready( function () {
>> ....... $('#«idOfHeadline»').css('color','«color»');
>> ..... });
>> .. </x:javascript>
>>
>> Kennt jemand eine Extension, die ein solchen Viewhelper oder ähnlichen
>> schon verwendet, so dass ich mir den Programmieraufwand ersparen kann?
>> Habe ich eventuell im VHS/Fluid-Extension einen solchen Viewhelper
>> übersehen? Für Tipps bin ich dankbar.
> Wenn es sich um eine eigene Extension handelt, habe ich es oftmals so
> gelöst:
>
> In das Extension-Template schreibe ich zuoberst
>
> <script>
> 	var color = {color}
> </script>
>
> Diese Javascript-Var kann ich dann im Extension-Javascript aufrufen.
>
> Man muss natürlich aufpassen, wenn man mehrere Plugins der Extension auf
> einer Seite einbauen will. Dann musss die Variable noch mit der Content
> ID verknüpft werden, um es eindeutig zu machen.
>
> Beste Grüße
> Stefan
>
Der Work-Around bringt Nachteile mit sich, wenn man größere Datenmengen 
übermitteln will. Aber auch hier gibt es natürlich Möglichkeiten zum 
Work-Around.

Ich verfolge beim Templating-Programmieren immer den Grundsatz, dass 
jeder View (Template/Partial) immer eigenständig - also unabhängig vom 
Rest der Seite –  existieren, definieren und  interagieren können muss.
Unter diesem Paradigma ist es zur Erhöhung der Transparenz des Codes 
manchmal sinnvoll, wenn man direkt im Template einen parametrisierten 
Funktionsaufruf von javaScript ausführt, statt ihn in eine externe 
JavaScript-Datei auszulagern.

Für die HTML-JavaScript-Trennungs-Puristen in der Leserschaft sei neben 
den Funktionstest ein weiteres Beispiel für sinnvollen 
JavaScript-Einsatz im HTML genannt.
Um ein Kontaktformular schnell zu machen, sollen die Eingaben per 
JavaScript validiert werden. Die Fehlerhinweise  zu den einzelnen 
Feldern könnte man natürlich jeweils als Data-Attribute bei den 
Input-Feldes hinterlegen. Man könnte sie aber auch direct als 
Javascript-Objekt an die Validierungsfunktion übergeben, um so unnötige 
data-Abfragen zu vermeiden und um so den JavaScript-Code schlank zu 
halten. Mit dem obigen Workaround, der für kleine datenmengen durchaus 
gut funktioniert, würde es schnell unübersichtlich werden.

Ich glaube, ich werde langfristig um den viewhelper 'fluidbracket' zum 
modifizierten Rendern von JavaScript nicht herumkommen und ihn wohl 
selbst programmieren müssen. *schade*

Mit besten Grüßen
    Dieter