PHP Code in externer Datei

[Camping_RIDER]

Aloha ;)

Tatsächlich?

Syntax-Highlighting und Precompiler sollten mit Platzhaltern genauso arbeiten, da valides JS erzeugt wird […]

Wird es nicht. Gehen wir von folgendem Template aus:
var foo = '<?= $foo ?>';
Und im PHP:
$foo = "arrr'rrrk";
Das fertig gerenderte Template, sähe dann so aus:
var foo = 'arrr'rrrk';

Pardon, vielleicht hab ich mich nicht klar genug ausgedrückt. Syntax-Highlighting und Precompiler arbeiten doch (zumindest habe ich das so verstanden/beabsichtigt") nicht mit dem fertigen JS für den Client, sondern mit der Variante, in der die Platzhalter noch nicht ersetzt sind. Dieses Problem ergibt sich also real nicht. Diesen Fall müssen wir aber wegen mir nicht ausdiskutieren ;) wer welchen Präprozessor einsetzt und mit welchen Möglichkeiten dieser kompatibel ist, wird wohl jeder selber sehen und entscheiden müssen. Ich hab in 7 Jahren Javascript-Programmierung noch nie einen benutzt und hatte dafür auch noch keinen Bedarf. ;) Aber wie gesagt, Schwamm drüber.

Man könnte jetzt hingehen und das Anführungszeichen maskieren, die korrekte Ausgabe wäre dann:
var foo = 'arrr\'rrrk';

So, aber was wenn nun die Template-Variable nicht von einfachen, sondern von doppelten Anführungszeichen umschlossen wird? Das Ergebnis nach unserer Anpassung von gerade, wäre diesmal zwar kein Syntax-Fehler, aber auch nicht die Zeichenkette, die wir erwarten würden:

var foo = "arrr\'rrrk";

Ich gebe zu: In meinen beiden Beispielen sollten die Variablen keine String-Delimiter beinhalten. Das stimmt soweit. Die Zeichen ' und " kommen aber bei einfachen Daten kaum vor, meist geht es um alphanumerische Strings mit bestimmten Sonderzeichen (Da die Verwendung von String-Delimitern in Strings aber immer und überall problematisch ist, wird in fast allen Systemen auch konsequent auf deren Einsatz verzichtet).

Für diese konstruierten Fall, ließe sich wieder ein Lösung finden, aber um es kurz zu machen: eine allgemine Lösung für die Problemklasse erhält man nur, wenn man der Template-Engine gestattet die umschließenden String-Begrenzer selbst zu generieren. Also in etwa so:

var foo = <?= json_encode( $foo ); ?>

Das stimmt. Die einzige ALLGEMEINE Lösung ist JSON. Du hast den Vorteil gefunden, chapeau.

Trotzdem: Allgemeine Lösungen sind bekanntlich für einfache Fälle meist overpowered und mit mehr Aufwand als nötig verbunden. Deshalb würde ich für das gegebene Problem nach wie vor die anderen Wege vorziehen.

Du hast aber vollkommen Recht, es muss der Aspekt der Allgemeinheit, der bisher im Hintergrund stand, auch betont werden. Vor allem bei großen Systemen, die unabsehbar wachsen können, sind allgemeine Lösungen zu bevorzugen.

Grüße,

RIDER