Template Engine, Sinn und Unsinn.

[NorHei]

Diskussionen über Template Engines und dern Sinn und Unsinn hatten wir ja schon öffter, aber jetzt hatten wir in einem anderen Thread eine doch recht fruchtbare Diskussion zu dem Thema.

Dabei bin ich selbst als hartnäckiger Kritiker an dem Punkt angelang wo ich sagen mag: "Halt , hier macht das Sinn"

https://forum.WebsiteBaker.org/index.php/topic,25276.0.html

Da die Diskussion um TEs aber nicht in einen Modulthread gehört führ ich Sie mal Hier weiter.

Kurzfassung:
Also das Problem war das Modul Members welches genauso wie das Newsmodul und viele andere die Möglichkeit bietet im Backend eingene kleine Templates für die Erzeugung der Seite anzubieten.
Zur Zeit wird mit str_replace() ein kleines Set von  "Templatevariablen" angeboten die aber im prinzip sehr wenig Flexibilität Anbieten. Eine Templateengine kann das ganze natürlich wesentlich flexibler gestalten hat aber eventuell eine hohe Lernkurve die für das bedienen eines Modul backends eher nicht geeignet ist. Zudem entsteht durch das häufige aufrufen der in der view.php jede Menge Speicherbedarf und die Geschwindigkeit der Seite bricht kräftig ein.

http://web-developer-blog.com/2012/10/template-engines-im-vergleich-teil-3.html
http://www.phpcomparison.net/index.php?template%5Bphp%5D=on&template%5Braintpl%5D=on&template%5Bsmarty%5D=on&template%5Btwig%5D=on&test=assign

Jetzt stellte sich die Frage ob es eine Gute Idee wäre die TE einfach beim speichern der Seite das fertig compillierte Template speichern zu lassen und damit WB viel Arbeit zu sparen und dafür zu sorgen das alles schön schnell rennt.

Es Wurde darauf verwiesen das TWIG dies wohl beherscht allerdings enthüllt ein blick in die Doku das das was da Compilliert wurde zwar PHP  ist aber das es  beileibe nicht frei von Overhead ist .

The generated template for a Hello {{ name }} template reads as follows (the actual output can differ depending on the version of Twig you are using):

Code: [Select]

/* Hello {{ name }} */
class __TwigTemplate_1121b6f109fe93ebe8c6e22e3712bceb extends Twig_Template
{
    protected function doDisplay(array $context, array $blocks = array())
    {
        // line 1
        echo "Hello ";
        echo twig_escape_filter($this->env, $this->getContext($context, "name"), "ndex", null, true);
    }

    // some more code
}
Als PHP template wäre das ein :

Code: [Select]

Hello <? echo $name ?>Und escaped wird gefälligst vorher(Escape Filfer ist nicht immer automatisch gewünscht).

Keine Frage was da schneller rennt.
(Da wundert es auch nicht das die meisten TE ohne Caching immer noch deutlich langsamer und speicherhungeriger sind als PHP)
Was ich mich jetzt frage ist , gibt es TE die wirklich simplen PHP code erzeugen kann?
Wenn man den nämlich dann speichern würde müsste das ganze doch eingendlich ohen Overhead rennen können.
 

[cwsoft]

Hallo,

Was ich mich jetzt frage ist , gibt es TE die wirklich simplen PHP code erzeugen kann?

Für kleinere Projekte habe ich in der Vergangenheit gerne die Template Engine (TE) Savant benutzt. Diese verwendet PHP selbst, benötigt also keine "Lernkurve". Recht schnell und resourcenschonend ist wohl auch die TE Haanga (aber nie selbst benutzt).

Ich für mich unterscheide meist folgende Anwendungen:
Ist die Ausführung von PHP Code in Templates erlaubt, benutzte ich in der Vergangenheit meist PHP oder Savant. Ist PHP in Template nicht gewünscht, verwende ich fast immer Twig. Auch bei grösseren Projekten wirkte sich das oft nachgesagte langsames "parsen" bei TE dank dem Cachen der Seiten bisher nie wirklich aus.

Seit einiger Zeit verwende ich fast ausschliesslich Twig (bei ganz einfachen Projekten, bei denen Twig nicht bereits zur Verfügung steht, weiche ich in ganz selten Fällen auf pures PHP aus). Meine Vorliebe zu Twig hat auch damit zu tun, dass sich Twig nahe an Pythons Django TE ausrichtet (das ist aber eine andere Sache).

Denke Links zu Templateengines gibt es im Netz zuhauf, einige ausgesuchte hier:
http://fabien.potencier.org/article/34/templating-engines-in-php
http://it-republik.de/php/news/Template-Engines-vs.-PHP-058161.html
http://www.webresourcesdepot.com/19-promising-php-template-engines/

Gruss

[easyuser]

Man sollte bei dem Hin-Und-Her der Performance auch eine Sache nicht außer Acht lassen:

PHP Code selbst wird in C++ "umgewandelt", dann in "Assembler", dann geht's erst zur CPU. Nicht zu sprechen von den Datenpaketen, die alle auf ca. 1000Byte verkleinert werden (OSI-Schicht). Noch gar nicht zu sprechen, von den Zig-Routern, die zwischen A und B liegen, Firewalls, etc.

Das heißt das, was ein Computer/Server/Netzwerktechnik leistet ist im Vergleich zu dem "umständlich" erscheinenden Twig-Code eher zu vernachlässigen.

[frankwis]

Ich halte gar nichts von Template Engines. Nach meinem Verständis ist PHP selber die beste.

Code: [Select]

<?= $variable ?> kann ich überall einbauen, aufwändige Funktionen auslagen und das war´s.

[DarkViper]

Zupf mir jetzt nicht gleich den Kopf ab, wenn ich Deinen Post leicht korrigieren muss. Ich weiss, dass Du das Richtige meintest.

... PHP Code selbst wird in C++ "umgewandelt", dann in "Assembler"
...

Ersetze bitte 'Assembler'  durch 'Maschinencode' dann passts wieder.
Assembler ist auch nur eine, direkt an die Maschine angepasste, 'Hochsprache', die erst mal in reinen Binärcode übersetzt werden muss. [ geschrieben wird da z.B. MOV A,B und im Programmspeicher wird nach der Übersetzung dazu nur der HexWert C4 abgelegt. (ist nur ein nur Beispiel, keine echte Anweisung)]

Das heißt das, was ein Computer/Server/Netzwerktechnik leistet ist im Vergleich zu dem "umständlich" erscheinenden Twig-Code eher zu vernachlässigen.

Ich denke, das wolltest Du auch umgekehrt sagen:
Das heißt dass der "umständlich" erscheinende Twig-Code, im Vergleich zu dem was ein Computer/Server/Netzwerktechnik zur Auslieferung einer Seite sonst noch leisten muss, eher zu vernachlässigen ist.

[cwsoft]

@frankwii
Die PHP short tag Varianten sind erst ab PHP 5.4 standardmässig aktiviert, vorher muss man shorttags selbst aktivieren. Meine auch mal gelesen zu haben, dass sich die shorttags in manchen Fällen mit XML templates beissen. Der Unterschied ist aber nicht wirklich dramatisch

Code: [Select]

<?= $variable ?> oder halt ohne shorttags
<php echo $variable ?>

@blackbird: Weisst Du ob Dwoo noch aktiv weiter entwickelt wird?

[NorHei]

Also irgendwie hab ich das Gefühl da hat der ein oder andere den Anfangsthread und die Verlinkten Seiten ned richtig angeschaut.

Anfangsthread:
1. An einer solchen Stelle im Modulbackend kommt wan um irgendeine Form des Templating nicht herum.
2. Full PHP ist spätestens wenn man eine Seite die Groß genug ist das man mehrere Authoren hat ein absolutes Nein.
3. Selbst bei nur einem Kunden der dran bastelt ist die Wahrscheinlichkeit sehr hoch das er die Seite ausser Funktion setzt.(Welcher Kunde ist schon PHP Profi und ein fehlendes Komma oder so und wir bekommen ne hübsche Fehlermeldung und sonst nichts.)
 

Die Links :
Nehmen wir mal :
http://web-developer-blog.com/2012/10/template-engines-im-vergleich-teil-3.html
Der Unterschied in der Geschwindigkeit liegt im Sekundenbereich (0,6 sekunden zu 7,3 das ist Faktor 12)
Das ist extrem bemerkbar.
Der Unterschied in der Speichernutzung ist noch extremer (11kb zu 543kb das ist Faktor  49)

Was die Netzwerkebene betrifft, so ist die deutlich schneller. Ein Ping an  WebsiteBaker.org dauert bei mir etwa 0,15 Sekunden für Hinn und Rückweg übers Internet, lokal auf meinem Recher dauert das sogar nur 0,000051 Sekunden. Die ganze Netzwerkebene ist halt auch in C geschrieben und nicht in einer Templatesprache die innerhalb einer anderen Interpreter (Interpiler?) Sprache rennt.

Der Übliche Billighoster hat immer noch 1000-2000 Accounts pro Server und bei PHP maximal 32 MB Memorylimit. Also ist die Leistung eigentlich drastisch eingeschränkt.

Des Weiteren hebeln viele TEs die Servereigenen Optimierungmöglichk eiten wie Opcode Cache völlig aus.  Dies Möglichkeite sind meist in C geschrieben und damit um längen effektiver als ds PHP basierte Caching von PHP. (Nebenbei bemerkt ist meines Wissens nach PHP auch in C geschrieben http://de.wikipedia.org/wiki/PHP )


Weiter gehts:

Das, was WB als TE mitliefert, ist heutzutage völlig indiskutabel.

Keine Frage



Deswegen hatte ich halt mal die Überlegung angestellt ob es nicht was gibt ohne die bekannten Nachteile. (JAA die haben auch Vorteile, zum Beispiel das es an der Stelle im Members Modul gar nicht anders Realisierbar ist, denn auch str_replace() ist ne TE)


@cwsoft :

Hmmm habe ich das richtig verstanden Savant ist sozusagen templating mit Plain PHP aber eben mit Hilfsfunktionen und einer Struktur drumm herum ? Gefällt mir als alter PHP Fan.

Das kammt aber eben leider grade im Module BE eher nicht in Frage
 weil volle PHP Power dort wohl wirklich nicht am rechten Platz ist.

Ziemlich praktisch fand ich die TE von Thorn in seinen PMF Modul. Da Thorn und sine Seite einfach verschwunden sind hänge ich mal die Doku als .zip an . Das Resultat waren einfache PHP Dateien die wirklich komplett ohne Overhead liefen. (und das im Server integrierte Caching nutzen konnten)

Eine deiner Links brachte mich dann hier hinn:
http://gonzalo123.com/2011/01/24/php-template-engine-comparison-part-2-versus-plain-php/

Dort wird Haanga erwähnt zumindest auf den ersten Blick macht die es offensichtlich so ähnlich wie Thorn.
http://haanga.org/
Leider ist die Lizenz ein wenig  

Ich sehe wirklich keinen Grund, warum man bei WB unbedingt den Weg gehen muss den alle anderen auch gehen.

[Stefek]

Da ich persönlich schon genug zum Thema "Sein oder Nich-Sein" für Template Engines geschrieben habe (und auch oft wirklich ermüdende Debatten daraus resultiert sind), will ich mich nicht weiter äußern.

Die beste Begründung, die ich geben konnte, ist in diesem Post zusammengefasst:
https://forum.WebsiteBaker.org/index.php/topic,25276.msg172279.html#msg172279

Ich freue mich, dass die nun eingebaute TWIG besser ist, als das was wir bisher hatten und dass es viele Codeschreiber gibt, die diese TE für brauchbar halten.

Alles andere wird sich in der Praxis entscheiden.

Ich denke CWSoft hat mit seinen Modulen gezeigt, dass die Syntax keine besonders hohe Lernkurve für den Layouter darstellt. Und selbst wenn - es gibt hier ein Forum, wer Fragen zum Thema Gestaltung haben wird, wird fragen und wie immer antworten bekommen.

Gruß,
Stefek

[NorHei]

Jep shorttags sind erst ab 5.4 standard (leider) also funktioniert das nur auf etwa der Hälfte aller Server.

Das Problem ist das Ich zum Beispiel die PHP Syntax auswendig kenne aber für die blöden TEs immer erst in die doofe Dokumentation schauen muss, es gib ja mehr als nur WB und TWIG und da sind immer wieder ettliche Kleinigkeiten anders. Das ist echt wiederwärtig.

Wer meint die Syntax einer TE ist soo viel leichter muss nen Knoten im Hirn haben. Aber ich tippe da dann ma auf Designer ohne PHP Vorkenntnisse. Die Unterschiede in der Sytax sind eher ... minimal, wer Programmieren kann versteht das eine So wie das andere. Und ja, ein Wenig einfacher ist die Syntax. Aber einen Vorteill muss ich wirklich einräumen, und zwar das sie Fehler besser verzeihen kann. (Fehlende Kommas und sowas ) Ansonste gilt : "Alles was ich schon kannn ist natürlich leicht".

Nebenbei bemerkt ging es beim Ursprungsthread um das Backend eines Modules und da kann man keinem zumuten 100 Seiten Doku zu lesen da sollte bei den Vorgefertigten Sachen auf jeden Fall keine komplexe Templatelogik drinn sein sondern nur einfache Ersetzungen. Das man auch Komplexe Sachen machen kann ist ja OK aber das sollte nicht der Standard sein sonst muss der Anwender sich nämlich doch erst durch viele Seiten Doku wälzen und das gibts bei anderen CMS schon oft genug

Du findest garantiert auch Seiten, die genau das Umgekehrte behaupten.

Ohhh, Nö ....keine gefunden, denn ->

Klar ist: Nichts ist schneller als reines PHP

Erfahrungsgemäß ist Jede Abstaktionsebene um den Faktor 10-100  Langsamer als ihr Vorgänger bei TEs ists etwa Faktor 10 (oder 100 bei Typo ) Deswegen war ich ja auf der Suche nach einer TE die dieses Problem dadurch löst das die Zeit an anderer Stelle aufgewendet wird als wenn die Siete ausgeliefert wird. Sie vielleicht eine Compiler bietet der nicht so einen Overhead erzeugt wie der von TWIG wobei der von TWIG ja schon besser ist als nichts.

[NorHei]

Ohne mir den Code jetzt angeschaut zu haben, wer was Einfaches sucht, kann ja mal einen Blick in die TE von F3 (Fat Free Framework) werfen.

Schaut ned schlecht aus.

[Stefek]

Das Problem ist das Ich zum Beispiel die PHP Syntax auswendig kenne aber für die blöden TEs immer erst in die doofe Dokumentation schauen muss, es gib ja mehr als nur WB und TWIG und da sind immer wieder ettliche Kleinigkeiten anders. Das ist echt wiederwärtig.

Mach Dir keinen Kopf um die Syntax.
Die Grundsyntax von TWIG ist kinderleicht.
Ich vermute mal, Du willst in Deinen Modulen nicht ALLE in TWIG vorhandenen Möglichkeiten ausschöpfen.

Es geht eben mehr mit TWIG als mit str_replace.

Schau Dir doch mal die vorhandenen fertigen Module von CWSoft an, die bereits mit TWIG laufen.
Wo ist das denn kompliziert? Weder die Layout-Schicht noch die Code-Schicht ist überwältigend.

[easyuser]

@Werner:

Nein, ist so völlig korrekt. Ich wollte nur damit sagen, dass hinter den Kulissen so dermaßen viel passiert, was niemand mitbekommt. Wird ja kaum einer
mov  eax, DWORD PTR [rbp-8]schreiben wollen.

[cwsoft]

@norhei
Savant entspricht in etwa dem was Contao als TE anbietet.

@norhei, frankwis
Meines Wissens kann man short tags über PHP aktivieren, ob das immer geht, weiss ich nicht. Bleibt dann noch die XML Template Geschichte.

Bei den Anynews-Templates hält sich die Lernkurve in Grenzen und viele Wünsche konnten einfach über ein angepasstes Template realisiert werden, statt wie zuvor über den Anynews PHP Code. Da ich Members nicht nutze, weiss ich nicht ob sich eine TE für Members wie bei Anynews lohnt.

Mir ist ist Weiterentwicklung, grosse Userbasis, vernünftige Doku und Standardisierung einer TE lieber, als wenn nun jedes Modul seine eigene Templateengine mitbringt. Twig wird mit WB ausgeliefert, warum also nicht verwenden.

[NorHei]

Das ist ein Punkt der mir einfach aufgrund der Vielzahl der TEs sehr auf den Geist geht, oder weist Du auswendig die Sytax von Smarty, Twig, PHPLib, Quickskin und Typoscript? Mit dem Gesülze musste ich mich bis jetzt rumplagen.
Man muss halt immer wieder nachschauen    

[NorHei]

@cwsoft
Shorttags ist ne Compiler Option, kann aktiviert werden wenn mit rein compliliert, sonst ned.

Wer wie bei Anynews mit nem Editor im Dateisystem unterwegs ist kann ganz andere Sachen als ein Anwender im BE.
Ich habe aber auch nur gesagt das das Standard Template nicht komplex sein soll, nicht das man die Möglichkeiten abschalten soll. 

[NorHei]

Frage: Schluckt Dwoo auch Strings aus ner Datenbank ?

[Stefek]

Nö. Ich such mir eine aus, die mir gefällt, und die nehm ich dann. Deren Syntax weiß ich dann und fertig. Wobei Du ja gesehen hast, daß ich tatsächlich die Varianten aller TEs kenne, die ich bisher benutzt habe, selbst die von Perl, was schon Jahre her ist. Für den Rest gibt es die Doku.
...
Aufgeregt hat mich das noch nie, obwohl ich schon mit vielen unterschiedlichen TEs gearbeitet habe. daher kann ich das jetzt auch nicht nachvollziehen.

Richtig, sehe ich auch so.
Man weiß es dann eben - und wenn nicht, schaut man nach. Es ist nun wirklich nicht so kompliziert.

Vorteil mit TWIG in WB kann dann aber sein, dass wir dann zum ersten Mal eine wirklich brauchbare TE global verwenden können, statt viele unterschiedliche "Mitbringsel". Bin mir sicher, dass Dwoo von Ralf nie benutzt worden wäre, wenn TWIG schon vorhanden gewesen wäre - es war der Mangel an einer logischen TE, der uns immer wieder auf die Suche getrieben hat.

[Stefek]

Frage: Schluckt Dwoo auch Strings aus ner Datenbank ?

Häh?

@BB
Gemeint ist wohl das hier:
https://forum.WebsiteBaker.org/index.php/topic,25276.msg172328.html#msg172328

[cwsoft]

Wer wie bei Anynews mit nem Editor im Dateisystem unterwegs ist kann ganz andere Sachen als ein Anwender im BE.

Anynews hat keinen Editor im Backend. Die Anynews Templates könnte man auch einfach als ein Forminputfeld ähnlich den Schleifen im News Modul über das Backend realisieren und statt als Datei halt in der Datenbank des Moduls speichern. Ich habe das halt über dateien gelöst, muss man aber nicht.

[mr-fan]

Wer wie bei Anynews mit nem Editor im Dateisystem unterwegs ist kann ganz andere Sachen als ein Anwender im BE.

Anynews hat keinen Editor im Backend. Die Anynews Templates könnte man auch einfach als ein Forminputfeld ähnlich den Schleifen im News Modul über das Backend realisieren und statt als Datei halt in der Datenbank des Moduls speichern. Ich habe das halt über dateien gelöst, muss man aber nicht.

Interessante Debatte....das wäre die nächste Frage gewesen.

Arbeite viel mit Dwoo und Ralfs Modulen.....aber wie schon erwähnt ist TWIG das gleiche in grün und wenn es eine Standard in WB werden sollte soweit aktuell und technisch auf Stand auch nur zu begrüßen...hier sind "detail pro/contra" fragen sowieso unnütz.

Meine Frage wäre gewesen - kann man das mit den TWIG Templates genauso (oder besser) gestalten wie mit den Settingsschleifen?

Das ist das einzige was mir in den Admintools der phpmanufaktur machmal fehlt - da ich nicht immer Zuhause meine IDE mit FTP Zugang und zwei Bildschirmen laufen habe.

Meinetwegen ein wenig versteckt oder im optimalfall per globaler Berechtigung gesperrt/frei ein Button in jedem Modul [Templates] und dann eine Liste/Formular für deren direkte Bearbeitung....

Im wesentlichen sind z.B. bei den Dwoo Modulen die Templates die früheren Settings nur übernehmen diese noch die Darstellungslogik.. .da wo ich z.B. in Members oder Topics mit Droplets "provisorisch" 2-3 Abfragen implementiert hatte.
(Wenn Wert=1 oder ' ' dann mach dies)

Um mehr geht es doch hier nicht. Die Frage ist wie man TE _einfach_ zur Verfügung stellt und _einfach_ in ein grundsätzlich _einfaches_ CMS einbaut. So dass man nicht Ostereiersuchen gehen muss (Wo waren jetzt hier bei diesem Addon die Templates, oder hmm da muss ich erst die Doku lesen damit ich den Link anzeigen lassen kann wenn in diesem Feld eine 1 steht!!!)

Gruß mr-fan

[Stefek]

Arbeite viel mit Dwoo und Ralfs Modulen.....aber wie schon erwähnt ist TWIG das gleiche in grün und wenn es eine Standard in WB werden sollte soweit aktuell und technisch auf Stand auch nur zu begrüßen...hier sind "detail pro/contra" fragen sowieso unnütz.

Richtig. Das gleiche in grün.
Die Syntax unterscheidet sich auch kaum. Oder anders ausgedrückt: wer das eine kann, dem fehlt nichts, um nicht auch das andere zu verstehen.

Meine Frage wäre gewesen - kann man das mit den TWIG Templates genauso (oder besser) gestalten wie mit den Settingsschleifen?

Das ist das einzige was mir in den Admintools der phpmanufaktur machmal fehlt - da ich nicht immer Zuhause meine IDE mit FTP Zugang und zwei Bildschirmen laufen habe.

Meinetwegen ein wenig versteckt oder im optimalfall per globaler Berechtigung gesperrt/frei ein Button in jedem Modul [Templates] und dann eine Liste/Formular für deren direkte Bearbeitung....

Theoretisch ja.
Du kannst die Layout-Strings einfach in die Datenbank schreiben, anstatt der jetzigen (z.B. im NEWS) str_replace Strings.
Oder Du kannst sogar das so machen, dass die Layout-Felder (die Textareas) mit Strings aus Dateien befüllt werden.
Also im Klar-Text: man muss sich nicht unbedingt der DB bedienen, man kann auch aus den Settings heraus in Files schreiben und aus Files lesen. Wie einem bequemer.
(Da die fertigen Templates gecached werden, macht es kaum einen Performance-Unterschied, d.h. theoretisch.)

Gruß,
Stefek

[Stefek]

Die Anynews Templates könnte man auch einfach als ein Forminputfeld ähnlich den Schleifen im News Modul über das Backend realisieren und statt als Datei halt in der Datenbank des Moduls speichern. Ich habe das halt über dateien gelöst, muss man aber nicht.

Man könnte tatsächlich jedes Feld (HEAD, LOOP, FOOT) und so weiter einzeln zerbrüseln, sodass man wieder für all das ein einzelnes Layout-Feld unter Einstellungen des Modules hat (ich gehe jetzt von NEWS aus), doch ich denke (finde), dass wenn man schon mit einer logischen TE arbeitet, kann man auch getrost alles in einer Datei/String inkl. Loop etc machen (so wie bei AnyNews).
Dann hätte man nur noch eine Datei/String für das NEWS und eine für den NEWS-OVERVIEW.
Na, eine noch für Comments und eine für das Comments-Form. (Ausgehend vom Newsmodul.)

Das Zerbrüseln der Strings in (HEAD, LOOP, FOOT) etc. halte ich im Fall von TE überflüßig.
Wie sehen es die anderen?

[cwsoft]

@mr-fan
Dafür bietet sich template_from_string an, was mit Twig 1.11.0 eingeführt wurde.

Die aktuelle WB Twig Version im SVN ist schon etwas älter 1.7.0 und sollte VOR dem Release von WB 2.8.4 noch aktualisiert werden (aktuell ist v1.11.1). Ist halt der Vor- bzw. Nachteil von noch aktiv weiterentwickelten 3rd Party Packeten  

P.S.: Auch jQuery (1.8.2 --> 1.8.3) und jQueryUI (1.9.2 --> 1.9.3) sollten vor WB 2.8.4 noch aktualisiert werden (wie ggf. weitere 3rd Party Packete)

[mr-fan]

Das Zerbrüseln der Strings in (HEAD, LOOP, FOOT) etc. halte ich im Fall von TE überflüßig.
Wie sehen es die anderen?

Naja mann kann das in Modulen wo es ansich logisch ist schon für die Eingabe machen und dann in ein Template gießen....das wäre halt einfach.

Die Settingsfelder waren grundsätzlich schon gut durchdacht und diese konnte man bis auf Abfragen und ein paar andere Dinge schon sehr sehr gut anpassen!

Bei einem Dwoo Addon von Ralf gibt es an sich eine andere Logik in der das genau so abgebildet ist.

Es gibt z.b. ein post.view.tpl  Template das unter bestimmten Umständen auf das post.detail.tpl zugreift und ebenso auf das post.teaser.tpl - also Detail oder Übersichtanzeige wird gleich im Template bestimmt. Die Templates/Schleifen sind getrennt und nicht in einem. Wenn dieser Parameter gesetzt ist zeige mir dieses Template.
(Sehr spannend wird das ganze z.B. in KitIdea - mit eigenem Berechtigungssystem, Übersichten, Detailansichten, Gruppenaufteilung, Frontendeingabe, integriertem Login alles mit dem Admintool Templatesystem hier die Übersicht zu behalten ist schwer...)

Das ist ansich komplex - die ganze Logik ein ein einziges Template zu packen ein wenig weniger und bei z.B. Anynews geht das soweit auf Github überflogen recht schön.

Aber was ist mit komplexeren Modulen wie z.B. Topics oder auch Members mit z.B. Übersicht und Detailanzeigen?

Alles zerteilt in Files ist komplex - alles in ein Template vielleicht auch.

Die zumindest für die Eingabe/Änderung im Backend nötige Aufteilung in (nenne es mal dausprachlich) "Ausgabebereiche" ist hier eine Überlegung wert.

Pro Template eine Datei spricht wiederum für eine einfache Möglichkeit Presets zu installieren bzw. zu verweden.

Template Datei hochladen -> Auswahlliste für die Anzeige mit Hilfe des jeweiligen Templates...fertig ist ein einfaches Presetsystem für ein Seitenmodul...

Aber ihr werdet da schon was passendes finden.

Wollte nur meine Erfahrung mit Dwoo und komplexen(=vielen Templates) hier einbringen.

Frage für weiteres von Profis:

a) ist es möglich mit einem Templatefile zu arbeiten? z.B. Addons Unterordner /presets/meine-frontend-ausgabe.tpl

b) dabei aber im Backend die Settingsbereich zu trennen in "einfache" "dem Modul angepasste" "logische" Abschnitte für die Bearbeitung/Veränderung zu Unterteilen?

c) ein sehr einfaches Presetsystem für TWIG Templates bereitzustellen das verwedet werden kann....ala Listenauswahl mit Anzeige und Auswahl aller Templates in /presets/ - ist das möglich?

Eine Templateengine scheitert doch meist an zwei Punkten:

1. Kann man als Designer (bei WB auch als DAU!!) schnell und einfach ändern?
2. Kann man die Optik schnell und einfach austauschen?

Und je mehr Logik vom Modul ins Template/im schlechteren Fall viele Untertemplates wandert umso schlechter schneiden bei Punkte ab!

gruß mr-fan

[Stefek]

Das Zerbrüseln der Strings in (HEAD, LOOP, FOOT) etc. halte ich im Fall von TE überflüßig.
Wie sehen es die anderen?

Naja mann kann das in Modulen wo es ansich logisch ist schon für die Eingabe machen und dann in ein Template gießen....das wäre halt einfach.

Die Settingsfelder waren grundsätzlich schon gut durchdacht und diese konnte man bis auf Abfragen und ein paar andere Dinge schon sehr sehr gut anpassen!

Nun, dass die Setting-Felder aufgebrüselt sind in die verschiedenen Bereiche wie (head, loop, foot) liegt hauptsächlich daran, dass man mit str_replace() keine andere Möglichkeit gehabt hätte (man kann damit nämlich werder eine while-Schleife noch sonst etwas "logisches" machen; daher wurde das in getrennten Feldern gemacht).

Das ist ansich komplex - die ganze Logik ein ein einziges Template zu packen ein wenig weniger und bei z.B. Anynews geht das soweit auf Github überflogen recht schön.
Aber was ist mit komplexeren Modulen wie z.B. Topics oder auch Members mit z.B. Übersicht und Detailanzeigen?
Alles zerteilt in Files ist komplex - alles in ein Template vielleicht auch.

Bei Members an sich ist es nicht viel komplexer als das AnyNews.
Ein Loop eben.

Pro Template eine Datei spricht wiederum für eine einfache Möglichkeit Presets zu installieren bzw. zu verweden.
Template Datei hochladen -> Auswahlliste für die Anzeige mit Hilfe des jeweiligen Templates...fertig ist ein einfaches Presetsystem für ein Seitenmodul...

Ja. Ich denke jedoch nicht, dass etwas dieser Art in naher Zukunft vom Core gehandhabt wird.
Man könnte aber in dieser Richtung auf jeden Fall was machen, ich habe ein Konzept, doch wenig Zeit, es umzusetzen:
https://forum.WebsiteBaker.org/index.php/topic,25276.msg172173.html#msg172173

Gruß,
Stefek