hat das Auswirkungen ob ich in Templates [%- INCLUDE oder [% INCLUDE mache und wenn welche?

nein
das extra minus sagt dem template system, dass das \n davor beim interpolieren gelöscht werden soll
so vermeidest du duzende newlines im generierten html code
funktional ist das identisch
interessantere unterscheidung ist INCLUDE vs PROCESS. die machen auch beide das gleiche, aber INCLUDE macht nen neuen variablen namespace auf, während PROCESS den aktuellen namespace weiterverwendet. das klingt trivial, ist aber ein riesiger performance unterschied, wenn du das in schleifen benutzt
solange dein subtemplate selber keine variablen setzt, also SET benutzt, solltest du immer PROCESS nehmen
Jein, Sven.
ok
mosu weiß mehr und erklärt
Weniger offensichtlich aber genau so betroffen: FOREACH
stimmt, implizites set
woernie: Wenn du ein Template mit INCLUDE inbindest, dann wirken sich sämtliche Änderungen an Variablen innerhalb des Sub-Templates auch auf das Haupttemplate auf.
Wenn du also z.B. im Haupttemplate so etwas machst: [% FOREACH row = SELF.items ] [ INCLUDE '_row.html' ] [ END ]…
…und im Sub-Template irgendwo [
FOREACH row = some_array ]…
…so geht das garantiert in die Hose.
äh
Quark
Ich meinte PROCESS in meinem Beispiel.
Also genau andersrum, als gorash sagt?
INCLUDE = alle Variablen werden kopiert, langsam, aber Änderungen im Sub-Template haben keine Auswirkungen.
PROCESS tut das halt nicht
PROCESS = schnell aber gefährlich, weil Änderungen im Sub-Template sich auf alles andere auswirken
Das gleiche gilt nicht nur für Sub-Templates (also Dateien), sondern auch für Blöcke, die mit [
BLOCK name ] … [ END %] deklariert und danach mit INCLUDE/PROCESS benutzt werden.
Meine persönliche Faustregel ist, dass alles, was in einer Schleife eingebunden wird, eher PROCESS sein sollte, alleiun aufgrund der Geschwindigkeit. Und darauf müssen die Sub-Templates dann halt designet sein.
Wenn man aber bei einer kompletten Seite ein gewisses Sub-Template nur ein einziges Mal einbindet, dann ist der Performanceunterschied halt nicht wirklich entscheidend (es sei denn, man hat wiederum sehr viele von solchen Sub-Templates).
der performance hit ist leider wirklich nicht trivial. ich hab das das erste mal bei cvar templates pro position gemerkt, und ich glaube da war der overhead im bereich 200ms für 10 positionen
subtemplate als block schreiben und einmal einbinden hilft tatsächlich