Template Engine, Sinn und Unsinn.

[DarkViper]

Eigentlich ist die Wahl des Systems ganz einfach, wenn man mal das Ganze betrachtet und nicht immer nur jeweils einzelne Teilbereiche.

Was muss ein Designer für die hier diskutierten Methoden können ?

Anzeige und einfache Logig per TE(Twig)  => beherrschen der Grundsynatx von Twig
Ein Teil der Anzeigelogik im PHP-Code  => beherrschen und verstehen des PHP-Codes
Zusätzliche Presets  => beherrschen des Presets-Systemes

Was muss ein Designer nach unserer geplanten Komplettmethode können?

Vollständige Trennung von Programmlogik und Anzeigeschicht => für den Anfang die Beherrschung etwas erweiterter Twig-Grundsyntax... fertig

Ich denke, die Wahl fällt da nicht besonders schwer.
Man muss sich nur eben mal aufrappeln und bereit sein, neue -teilweise noch- unbekannte Wege zu gehen.

[cwsoft]

@mr-fan:

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

Auch komplexere (sprich mehrere Templatedateien) sind beherrschbar. Hier schafft man halt Ordnung und Klarheit durch eine aussagekräftige Benennung des Templates wie z.B. hier. Haben Templates einen vernünftigen Namen, findet man sich recht einfach zurecht.

Es hilft auch, wenn logische Blöcke die öfters verwendet werden in einer Datei ausgelagert werden und dann einfach in einem anderen Template wieder eingebunden werden (DRY). Auch Template "Vererbung" und "Includes" sind kein Hexenwerk und helfen meist das Chaos zu minimieren, wie z.B. hier (frontend, backend, count_characters) geschehen.

Konstrukte wie {% include 'count_characters.ht t' %} überlese ich dann halt, wenn mich dieser Teil nicht interessiert und konzentriere mich auf das was zählt.

Denke wenn sich erstmal ein "Standard" etabliert hat, sind viele dieser "Diskussionen" obsolet.

[Stefek]

@DarkViper

Zusätzliche Presets  => beherrschen des Presets-Systemes

Könntest Du bitte kurz anreißen, was Du mit Preset-System meinst und wie es ungefähr aussehen würde?

Ich habe das starke Gefühl, dass sowohl Mr-Fan, als auch ich, mit Presets etwas anderes meinen, als Du.

Gruß,
Stefek

[mr-fan]

Was muss ein Designer nach unserer geplanten Komplettmethode können?

Vollständige Trennung von Programmlogik und Anzeigeschicht => für den Anfang die Beherrschung etwas erweiterter Twig-Grundsyntax... fertig

Ich denke, die Wahl fällt da nicht besonders schwer.
Man muss sich nur eben mal aufrappeln und bereit sein, neue -teilweise noch- unbekannte Wege zu gehen.

Fallen da die von cw-soft angepassten Module rein...dann hätte man ja schon eine Art Beispiel das bei Bedarf auf andere Module angewendet werden kann?

Denke solch ein großer Schritt hängt immer davon ab, inwiefern ein einfacher Modulentwickler weis das es in die richtige Richtung geht.

@Stefek: Hier wäre eine neue Methode, eigene Presetverwaltung, oder sonstige extras wohl nicht angebracht sondern schlicht auf den Punkt gebracht wie man TWIG nutzen könnte Module und Templates aufzuzbauen.

Sicher sind die Module von cw-soft eine Referenz auf Github, aber hierraus kann man ja (warum nicht in dieser Disskusion) sofort Grundsätze ausarbeiten wie TWIG (als gemeinsamer von WB unterstützter Nenner) für Modulautoren "am einfachsten" Anzuwenden ist.

Also schlicht wie käme man in einem Standardseiten Modul ala Memebers, News sonstwas auf eine einfache Umstellung auf Twig.

Das wäre ein Nutzen, Mehrwert der über die reine Disskusion hinausgeht. Und mehr bringen würde als wenn zwei Leute ein altes Modul aufbohren.

Jetzt nicht mit Modulguidelines anfangen....ich denke Werner wird sofort korrigieren wenn etwas so nicht ginge.

Twig ist gut - soweit konsens - Sollte eingesetzt werden - ebenso.

Einzig konstruktiv wäre jetzt das wie zu klären - und dann ist das fruchtbar und nutzbar für alle die daran Interesse haben sowie ich.

@cw-soft: Wie bist du die Umstellung deiner Module angegangen - was wäre hier die beste vorgehensweise?

@DarkViper

Zusätzliche Presets  => beherrschen des Presets-Systemes

Könntest Du bitte kurz anreißen, was Du mit Preset-System meinst und wie es ungefähr aussehen würde?
Ich habe das starke Gefühl, dass sowohl Mr-Fan, als auch ich, mit Presets etwas anderes meinen, als Du.
Gruß,
Stefek

Denke er meint - keine Presets verwenden - nur Templatefiles sonst nichts?
(Wäre auch in Ordnung so geht das bei Ralfs Admintools auch reine Templatedateien im Ordner per Parameter bestimmt man unterschiedliche Presets.)

Bitte nicht für mich mitmeinen - könnte schon selber fragen...

@Werner - hier wäre grundsätzlich interessant wie du die Frage nach unterschiedlichen Templates in unterschiedlichen Seiten/Abschnitten angehen würdest? Also meinetwegen Members 3 mal mit unterschiedlichen Templates in Verwendung?

[Stefek]

Bitte nicht für mich mitmeinen - könnte schon selber fragen...

Nun ja, ich gehe davon aus, dass Du bezogen auf Presets sowas meinst, wie bisher in z.B. Members zu finden ist, was also solls.

@Stefek: Hier wäre eine neue Methode, eigene Presetverwaltung, oder sonstige extras wohl nicht angebracht sondern schlicht auf den Punkt gebracht wie man TWIG nutzen könnte Module und Templates aufzuzbauen.

Das sind grundsätzlich 2 verschiedene Bereiche.

Ein Modul durch die TE zu ziehen ist nicht sonderlich schwer. Da wird es ebenfalls mehrere Herangehensweisen, abhängig vom Entwickler geben. Selbst wenn es eine "Vorgabe" gäbe, müßte man sich nicht zwangsläufig an eine solche zu 100% klammern. (Und bevor eine Art Guideline dafür kommt, werden Moduleentwickler sowieso auf ihre eigene Art mit der Twig arbeiten - falls sie sie überhaupt aufgreifen; viele werden es nicht tun).

Bei den Presets widerum ist es eine andere Sache.
Ich für mich denke da eher an "Plugins", die mehr als nur das Template und die Settings beinhalten.
(Ich denke aber nicht, dass auf so etwas hingearbeitet wird von den DEVs.)

Daher die Frage an @DarkViper, was er damit (=>presets) meint.

Gruß,
Stefek

[cwsoft]

@cw-soft: Wie bist du die Umstellung deiner Module angegangen

Na einfach Schritt für Schritt (sprich Datei für Datei) für alle Module: Postits, Anynews, AFE

[NorHei]

Jeder der Hier diskutierenden hat ein gewisses Maß an Programmiererfahrun g, Erfahrung mit HTML,CSS und meist auch verschiedenen TEs. Kein Wunder das da alles kein Problem ist.
Jetzt versucht euch mal in jemanden hineinzu versetzen der grade mal rudimentäre HTML Kenntnisse ala Selfhtml hat, Programmierung 0%, sprich ein Einsteiger. Aus eigener Erfahrung weiß ich das diese Leute mehr als glücklich sind wenn  sie sich weder mit Verzweigungen noch mit includes oder Sowas rumschlagen müssen. Die freuen sich drüber wenn das HTML schön in HEAD LOOP und FOOTER zergliedert ist in Verbindung mit ner netten Infobox   was die Grundsätzlichen Ersetzungen so Bieten... ENDE

Technisch sollte es doch gar kein Problem darstellen die 3 Boxen aus der DB zu fischenn aneinander zu hängen , noch das Loop Kommando einzufügen und dann durch die TE zu jagen.

Theoretisch würde das sogar bedeuten, das ein Profi einfach alles in den Head packen kann weil der leere Loop einfach nichts macht und der Einsteiger hätte strukturen die das verstehen drastisch vereinfachen.

Ich denk da So an meine ersten Erfahrungen mit einigen anderen CMS. Mann installiert das Script und scheitert im ersten Anlauf schon an dem erstellen der ersten Testseite scheitert. Was hab ich getan, ganz einfach das Dingen weggeworfen. Ich wollte Webseiten erstellen nicht Doku lesen, dannn hab ich WB installiert und ohne einmal in die Anleitung zu schauen eine Seite erstellt. Mit 10 minuten in die Doku schauen ein Template gebaut. Und nach ner halben Stunde lesen ein Modul gebaut und direkt noch eine Core Modifikation Nachgeschoben... einfach GEIL.

Irgendwie fällt mir da der Spruch einen CMS Jüngers von einem anderen CMS ein:

Code: [Select]

Hmmm jaaaa, das ist nicht intuitiv aber Du musst ja nur das hier im Wiki lesen und dann das hier in der Doku und vieleicht noch hier die Tutorials machen, dann ist alles gaaaanz einfach.   
Und wenn ich denke wie sich ein Einsteiger fühlt der das erste mal in ein Template mit Loops, Verzweigungen und
Includes anschaut dann ist das bestimmt schlimmer als meine ersten Erfahrungen mit C64 Basic. Zumal ich das Damals aktiv lernen wollte.

Es ist schön alles machen zu können, ohne Doku. Warum ist Apple so erfolgreich? Weil es so intuitiv ist, man brauch nicht lesen sondern kann machen. Und obendrein kann man mit so einem MAC auch noch alles tun was man mit einem vollwertigen UNIX Server anstellen kann, weils ein FreeBSD ist (Gut, erst wenn man ein paar Limits entfernt hat. ) So sollte es werden.

[cwsoft]

@Norhei

Naja für die meisten Sachen dürfte ne einfache Platzhalterersetzun g reichen, sprich {{ PLATZHALTER }}, das versteht jeder. Darüber hinaus noch  IF, ELSE Konstrukte und der LOOP. Alles andere  (z.B. Includes, Vererbung, Funktionen ...) sind Goodies die man nutzen kann, aber nicht muss. Ich denke in 90% der Fälle wird ein Template nicht komplexer als dieses hier werden. Die wichtigsten Twig Sprachkonstrukte kann man auch auf den Hilfeseiten mit Beispielen zeigen.

Bei WB Templates muss man auch ein paar Sachen lernen. Zum Beispiel wie man register frontend nutzt, loginboxen anzeigt, oder viel schwieriger sein Menü mit show_menu2 und CSS nach eigenem Gusto anpasst.

Ist aber wie alles im Leben eine Frage des Geschmackes.

[NorHei]

jep showmenu() könnte was zum vereinfachen gebrauchen

[easyuser]

Kleiner Exkurs zu Beginn:
Eine meiner interessantesten und lehrreichsten Erfahrungen mit Programmierung war das Leiten von Programmierern im Rahmen eines Projekt-Workshops. Ziel war es, in drei Tagen ein CMS zu programmieren. Wie war egal.
Wie soll man nun 10 Leute gleichzeitig arbeiten lassen?
Geht nicht, also ein Design Pattern genommen. Ich habe dafür ein Faible, diesmal nicht MVC, sondern das - wie ich finde für solche Fälle beste - Entity-Control-Boundary.
2 Leute haben Datenbankzugriffe (Entity) gemacht, 5 Leute die eigentliche Programmierlogik (Control) und 3 Leute mit Twig nur HTML / CSS / jQuery / "Twig-Code" (Boundary).
Das Ende vom Lied war, dass das Projekt zwar aus den Fugen geraten ist, am Ende aber sehr sauberer, nachvollziehbarer Code vorhanden war, beliebig erweiterbar. Echo wurde gänzlich verbannt, SQL gab es nur in einer einzigen gekapselten Klasse.
Und: Die 3 Leute vom Design mit Twig haben keinen einzigen Fetzen PHP gesehen - wozu auch.


Sicher ist das eine Traumvorstellung für WB (jedenfalls für mich), und wir können nunmal WB nicht mal eben umschreiben. Es soll lediglich zeigen, dass eine TemplateEngine extrem sinnvoll ist, wenn sie von A-Z durchdacht und in das Projekt integriert ist.

Ich finde es aus dem heutigen Zeitpunkt von WB und seiner Twig-Unterstützung eher schwer, sich das richtig vorzustellen. Zugegeben, ich kenne die Twig-Unterstützung von WB nicht im Detail.
Doch - damit es nicht ganz so trocken aussieht - ein Real-Beispiel für obiges "CMS" (zugegeben, die Bezeichnung ist falsch).

Es gibt eine wrapper.htt, leicht gekürzt:

Code: [Select]

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>
      {{ page.head_titel }}
    </title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <link rel="stylesheet" type="text/css" href="css/style.css" />
  </head>
  <body>
    <div id="site">
 <div id="top">
<div id="logo">
 {{ page.titel }}
</div>{% include 'top_nav.htt' %}
 </div>
 <div id="content">
<div id="left">
{% block content %} {% endblock %}
</div>
<div id="right">
{% include 'sub_nav.htt' %}
</div>
 </div>
    </div>
    <div id="bg_footer">
    </div>
  </body>
</html>

Sie ist die Basis. Eben der Wrapper, der immer gilt. Die "Quasi - index.php" also.

Die top_nav.htt exemplarisch stellt die Navigation in einem DropDown dar:

Code: [Select]

<div id="navi">
  <div id="navimain">
<ul id="header_menu" class="menu">
     {% for t_nav in topnav %}
<li>
 <a href="{{ t_nav.Url }}" class="{{ t_nav.Current }} navlev1">{{ t_nav.Title }}</a>
</li>
        {% endfor %}
</ul>
  </div>
</div>

Und last but not least eine richtig dargestellte Seite:

Code: [Select]

{% extends "wrapper.htt" %}
{% block content %}
<h1>
 Servus!
</h1>
<p>
 Bitte wählen Sie in der Navigation oben aus, was Sie tun möchten.
</p>
{% endblock content %}

So, det war's! Kein PHP, nada.
Sicher kann man sagen: "Warum nicht gleich PHP?".

Dann muss ich wirklich mal fragen: Was soll der Designer von heute alles können?
CSS und HTML wird hier immer als gegeben hingestellt, jQuery sowieso.
Doch alleine schon CSS ist für die meisten eine große Hürde - die Abstraktion in Zahlen ist sicher schwerer als man denkt.
Und zu dieser "künstlerischen Abstraktion" kommt noch die Programmierung dazu.
Sicher - wer sich die Mühe gemacht hat, PHP zu lernen wird blöd sein, wenn er es nicht mehr einsetzt. Oder Java, oder C#, oder JavaScript - ja, unterschätzt nicht JavaScript / ECMAScript, das wird in Umgebungen zu Zwecken eingesetzt, die man sich hier lieber nicht vorstellt. Und die Komplexität dazu auch nicht. jQuery ist auch nichts anders.
Und das ist noch lange nicht alles - für PHP und andere serverseitigen Geschichten kommt auch noch Sicherheit, Performance, Kompatibilitäten usw. ins Spiel.
Und es mag ein Klischee sein - aber ich kenne so gut wie keinen sehr guten Designer, der auch sehr gut programmieren kann. Andersrum übrigens auch nicht.

Aus oben genannten Gründen:
- Einfachheit
- Arbeitsteilung
- Leichte Dokumentierbarkeit
- Abgrenzung
finde ich eine sauber in WB integrierte Twig-Engine (meinetwegen auch eine andere, aber jetzt haben wir eine, jetzt lasst die doch mal bitte auch sein, zufriedenstellen kann man NIEMALS jeden), mit der ich auch alles ansprechen kann - vom Seitentitel über die Blöcke bis hin zu den Menüs - deutlich besser und flexibler als reines PHP.


Abschließend noch ein Wort zu Apple: Apple mag für die User ja recht angenehm sein - sie sind fast so erfolgreich wie Google mit ihrem Betriebssystem damit. Trotzdem hat Apple für die Millionen von Apps eine eigene (!!!!) Programmiersprache namens Objective-C 2.0 entwickelt (gut, zwischenzeitlich war der Vorgänger bei BSD, aber... das ist ja bekannt). Und das Faß Microsoft will ich gar nicht erst aufmachen.
Noch Fragen?

[badknight]

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

Als Programmierer bietet dir Twig 4 Möglichkeiten wie du eine Template verwenden kannst. Wobei - ich vermute - dass davon höchstens 2 Varianten oft genutzt werden:

Twig_Loader_Filesystem - ist die Variante was wir von jeder TE kennen - Datei öffnen, sachen reinschreiben - ausgeben

Code: [Select]

<?PHP
$templateDir = '/path/to/templates';

$loader = new Twig_Loader_Filesystem($templateDir);
$twig = new Twig_Environment($loader);

echo $twig->render('index.html', array('name' => 'Fabien'));
?>
Natürlich kann man das auch erweitern:

Code: [Select]

<?PHP
$templateDir1 = '/path/to/templates';
$templateDir2 = '/path/to/templates2';

$loader = new Twig_Loader_Filesystem(array($templateDir1, $templateDir2));
$twig = new Twig_Environment($loader);

echo $twig->render('index.html', array('name' => 'Fabien'));
?>


Twig_Loader_String() - hier wird die zweite Variante verwendet - ein Template anhand eines Strings verwenden:

Code: [Select]

<?PHP
$loader = new Twig_Loader_String();
$twig = new Twig_Environment($loader);

echo $twig->render('Hello {{ name }}!', array('name' => 'Fabien'));
?>

Damit kann man auch die in WB oft gesehenen "Datenbank Templates" verwenden.

Wobei man etwas bedenken muss:

several tags, like extends or include do not make sense to use as the reference to the template is the template source code itself.

Aber in Zeiten wo es Tools wie den AFE oder andre Module gibt, sehe ich da kein Problem Template- Dateien zu verwenden

Sicher kann man sagen: "Warum nicht gleich PHP?".

Deine Gründe sind vollkommen richtig, aber es kann auch noch andere Gründe haben:

- Man arbeitet mit mehreren Menschen an einem Projekt (wie es eine Firma ja öfters macht), nun will der Grafiker aber wieder bei gewissen Situationen andere Elemente haben etc. - bevor ich nun jemand meinen PHP-Code umschreiben lass, ist es mir lieber er hat eine vom PHP - Code unabhängige Möglichkeit das ganze zu machen.


Davon abgesehen:
Twig hat noch weitere nette dinge, die einen das Arbeitsleben vereinfachen können - wie z.B. Macros

Man erstellt sich eine Datei mit folgendne Code:

Code: [Select]

{% macro input(name, value, type, size) %}
    <input type="{{ type|default('text') }}" name="{{ name }}" value="{{ value|e }}" size="{{ size|default(20) }}" />
{% endmacro %}
speichert dies als forms.html (ob nun .htt, .twig oder what ever - macht in dem Beispiel keinen Unterschied )

Code: [Select]

{% import "forms.html" as forms %}Diesen kleinen Code in das gewünschte Template einbauen, schon hab ich ein nettes feature:

Code: [Select]

<p>{{ forms.input('username') }}</p>
<p>{{ forms.input('password', null, 'password') }}</p>
So kann ich mir schnell und einfach input felder erstellen.

Natürlich überlasse ich jeden selbst, welche Funktionen / Features er als hilfreich bezeichnet

[Stefek]

@Badknight

Aber in Zeiten wo es Tools wie den AFE oder andre Module gibt, sehe ich da kein Problem Template- Dateien zu verwenden

Außer, dass im Falle von Section-Modulen und Layouts fürs Frontend, kann es oft vorkommen, dass Du für jede Section des gleichen Modules ein anderes Template brauchst.
Dann wird die Arbeit mit AFE schon schwieriger und es würde sich in den Fällen empfehlen, entweder tatsächlich die DB vollzustopfen, oder eine Funktion zu haben, die in den Module-Settings die Layout-Files anzeigt und speichern läßt.


Gruß,
Stefek

[badknight]

@Badknight

Aber in Zeiten wo es Tools wie den AFE oder andre Module gibt, sehe ich da kein Problem Template- Dateien zu verwenden

Außer, dass im Falle von Section-Modulen und Layouts fürs Frontend, kann es oft vorkommen, dass Du für jede Section des gleichen Modules ein anderes Template brauchst.
Dann wird die Arbeit mit AFE schon schwieriger und es würde sich in den Fällen empfehlen, entweder tatsächlich die DB vollzustopfen, oder eine Funktion zu haben, die in den Module-Settings die Layout-Files anzeigt und speichern läßt.


Gruß,
Stefek

Da hast du schon recht, man muss sich immer ansehen um welches Modul es sich handelt.
Bei Gefühlte 80% der Modulen reicht es eine normale Template datei zu verwenden, da es keine Sonderwünsche vorhanden sind

[Stefek]

Ja.
Stimmt.
Eine Download-Gallery will man wohl nicht auf jeder Seite haben.
News wird wohl auch meistens nur einmal pro Seite verwendet.

Bei Modulen wie Members siehts dann allerdings anders aus.
Oder einem ExtendedWYSIWYG.

Ist schon je nach Modul verschieden. Gebe ich Dir recht.

Ich meine aber eben für die Fälle, wo man es per Section anders haben will,  muss man sich etwas einfallen lassen.

Gruß,
Stefek

[DarkViper]

Ich meine aber eben für die Fälle, wo man es per Section anders haben will,  muss man sich etwas einfallen lassen.

Das ist primär erst mal ein Problem des jeweiligen Modules. Wenn es mehrfache Instanzierungen unterstützt, so gehört da auch seine Templatezuweisung dazu.
Der Kern kann und darf an dieser Stelle nicht eingreifen, da er ja von den Internas eines Modules keinerlei Informationen hat(und die auch nicht braucht). Den Kern interessiert nur die allgemeine Schnittstellengesta ltung zur Einbindung also derzeit der Aufruf von view, install, modify, add, delete, upgrade, uninstall und evt. include.php. Mehr nicht. Alles andere wäre bereits wieder eine unzulässige, harte Verflechtung von Kern und Modulen.

Es werden später mit Sicherheit diverse Helper-Klassen vom Kern angeboten werden die jedoch in der aktuellen Codeumgebung noch nicht vernünftig realisierbar sind.

[Stefek]

Ich meine aber eben für die Fälle, wo man es per Section anders haben will,  muss man sich etwas einfallen lassen.

Das ist primär erst mal ein Problem des jeweiligen Modules. Wenn es mehrfache Instanzierungen unterstützt, so gehört da auch seine Templatezuweisung dazu.

Ja, das ist schon mal klar.

Sag mal, was meintest Du denn oben mit Preset-System ?

Zusätzliche Presets  => beherrschen des Presets-Systemes

Was ist da angedacht?

Gruß,
Stefek

[funas]

Sollte keine Diskusion wert sein.
In den Dateien herscht Chaos! Funktionen zwischen P Tags und keine Struktur. Einfach alles durcheinander geworfen. Nichts eingerückt und auf Qualität keine Rücksicht genommen...

Ich erstelle grad ein Modul und es ist fürchterlich, dass ich mein Array, mein Object nicht einfach assignen und ans Templates übergeben kann. Damit kann ich es mir und dem Benutzer einfacher machen! Und der Code bleibt überschaubar und Strukturiert.

[funas]

Nochmal schnell nachgefragt....

Wie ist denn der Stand?
Wird noch diskutiert ob eine, oder welche TE verwendet wird?

Ich würde ungern weiter machen, wenn ab morgen eine TE angeboten wird, die ich verwenden kann
Es sind nur 3 Zeilen Code und ne Datei die hineingepackt werden müssten!

Und die Engine müsste ja nichtmal verwendet werden.
Falls es wirklich ( ganz ernsthaft! ), jemanden gibt, der überfordert ist, die Syntax von variablen und ne foreach ( mehr ist es im normalfall nicht ) zu erlernen, der kann immernoch PHP HTML murks zusammen flicken...

Lasst es bitte nur nicht wieder im Sande verlaufen!

[easyuser]

Sollte keine Diskusion wert sein.
In den Dateien herscht Chaos! Funktionen zwischen P Tags und keine Struktur. Einfach alles durcheinander geworfen. Nichts eingerückt und auf Qualität keine Rücksicht genommen...

Ich erstelle grad ein Modul und es ist fürchterlich, dass ich mein Array, mein Object nicht einfach assignen und ans Templates übergeben kann. Damit kann ich es mir und dem Benutzer einfacher machen! Und der Code bleibt überschaubar und Strukturiert.

Blöde Frage, aber ich verstehe genau 0% von deinem Beitrag. 
- Wo / in welchen Dateien herrscht Chaos
- Wo ist keine Struktur?
- Wo gibt es keine Einrückungen und keine Qualität?
- Wo kannst du nichts übergeben und mit was?
- Mit was wird der Code strukturiert?

Bitte verstehe das nicht als Angriff sondern schlichtweg, weil ich nicht weiß, was du meinst. Und nehme mal an, ich bin hier nicht der einzige.

[Stefek]

@funas.

Wahrscheinlich hast Du es einfach noch nicht mitbekommen, aber es wird ab sofort die TE Twig im Paket angeboten.
Sie wird zwar noch nicht aktiv im Core verwendet, aber man kann sie bereits in Modulen verwenden. Soll der neue Standard werden.

Im aktuellen SVN ist sie drin, so auch in der nächsten WebsiteBaker Version 2.8.4

Gruß,
Stefek

[badknight]

twig wird bereits seit der 2.8.3er serie ausgeleifert

[funas]

dann ist gut, hab nichts gesagt

[Stefek]

twig wird bereits seit der 2.8.3er serie ausgeleifert

Hm.. ja, aber die gegenwärtige Implementierung wurde erst vor 8 Monaten eingesetzt:
http://project.websitebaker2.org/projects/wb28x/repository/revisions/1686

Gruß,
Stefek

[Stefek]

twig wird bereits seit der 2.8.3er serie ausgeleifert

Hm.. ja, aber die gegenwärtige Implementierung wurde erst vor 8 Monaten eingesetzt:
http://project.websitebaker2.org/projects/wb28x/repository/revisions/1686


// edit

im Download der 2.8.3 ist auch kein Twig im /include/ Ordner zu finden.

Gruß,
Stefek

[funas]

Das stimmt.
Wann wird es denn veröffentlicht? Also < 1852 ?
Gibts da Zyklen oder so?  

Gruß