nicht angemeldet
hi,
Und selbstverständlich kann man auch JS Code oder ganze JS-Dateien über gerenderte Templates ausliefern.
Das man das KANN, hat keiner bestritten. Dass das ein guter Weg ist, schon. Weil die Erzeugung von JS über Templates impliziert, dass sie relativ variabel sind. Und dann ist es nicht gut, sie zu cachen. Ich finde das auch schlecht testbar. Das generierte JS kann ja jederzeit anders aussehen.
Natürlich wird man nicht sämtlichen JS Code über Templates generieren. Aber es gibt Lösungen die sind gar nicht anders möglich. Ich habe ja nicht umsonst das Beispiel mit dem %url% Platzhalter gebracht: Während man in Formularen das action-Attribute einfach weglassen kann, ist das nämlich in Sachen XHR und fetchAPI nicht möglich, da muss ein URL notiert sein an welchen der Request gesendet wird.
Also wird bei mir für diesen Platzhalter grundsätzlich dieser Wert gesetzt und wird zu einer Variablen, die von JS genutzt werden kann. D.h., im Effekt ist es es gar keine Variable weil, bis auf wenige Ausnahmen, sämtliche AJAX//Fetch Requests die eine Seite feuern soll, stets auf sich selbst gerichtet sind. Was daran sollte denn da einen Test erschweren? Das Gegenteil ist der Fall!
Mitnichten sieht da ein JS jederzeit anders aus, vielmehr sieht es immer genauso aus wie es für die jeweilige Seite erzeugt wurde: Einheitlich. Also werden im Endeffekt die Tests sogar vereinfacht!
Was ja auch der Sinn eines Framework ist. Da wird nicht für jede Seite eine extra Wurst gebraten sondern Platzhalter für alle Seiten zum Prinzip erhoben. So erst wird die Sache einheitlich, wartungsfreundlich und skalierbar: Jede HTML Response ist ein Template. Und die Prozesse zum Einbau von Platzhaltern sind einheitlich.
Die TE wird also generell geladen, nur der Renderprozess kann abgeschaltet werden wenn er nicht gebraucht wird und das ist über ein Attribut zum URL konfigurierbar. Unabhängig davon ist auch konfigurierbar, ob die Seite gecached werden soll oder nicht. Wenn ich z.B. für Seite /index.html testen will ob ein Lastmodified Header gesendet werden soll, wird der Test zunächst die Konfiguration für diesen URL abrufen. Und wenn da drinsteht:
[/index.html]
no_cache = 1
class = HTMLTemplate
file = index.html
interface = date
darf die Response keinen Lastmodified Header senden was mit einem HEAD Request leicht zu prüfen ist. Ebenso können Name der class und der Name des interface abgerufen werden und fürs händische Debugging sind dies Angaben auch gleich im <head> zu finden damit man nicht lange rumsuchen muss wenn mal irgendwas nicht stimmt.
Und jetzt stell Dir mal vor, der URL für eine Seite wäre zu ändern. Das würde unweigerlich eine Änderung sämtlicher JS Dateien nach sich ziehen in denen der URL fest codiert ist!
Und mal angenommen, die Seite braucht weitere variable Komponenten in JS. Dann kann man auch mit <script src="%url%?js=ext"></script> ganze Code-Teile für JS dynamisch erzeugen und nachladen und je nach Umständen selbstverständlich auch cachen (Lastmodified). Und wenn eine solche Erweiterung über ein hinzukonfiguriertes Interface realisiet wird, steht dieses interface genausogut für jeder andere Seite zur Verfügung, was also jede Menge redundanten Code vermeidet.
Du siehst also, die Sache ist doch ein bischen komplizierter als daß man hier Aussagen der Art gut oder schlecht treffen kann.
MfG
Rolf B
TS
Auge