Können wir in Contao 3 … (zuerst lesen, dann aufregen)?

[tril]

Sicher, man kann andere Konstrukte nutzen (siehe oben), aber ob man damit immer alles abbilden kann, was man über PHP kann..... Zweifel.

Ja, das geht weil du eigene Konstrukte hinzufügen kannst.

Datenbankabfragen?

Prototyp aus meiner lokalen Entwicklungsversion (noch nicht auf github):

{% for row in "SELECT * FROM tl_content WHERE id=?"|dbquery(include_content) %}
  {# do somethink with row #}
{% endfor %}

(Ob der Filtername "dbquery" bleibt, weiß ich noch nicht, eventuell teile ich es auch in "prepare", "set", "limit" und "execute")

Includes?

Dafür gibt es {% include 'file.html' %}
http://twig.sensiolabs.org/doc/templ...ther-templates

Abgeänderte Inserttags?

Insert-Tags sind aktuell das größte Problem, weil diese den gleichen Syntax wie Twig haben. In Twig werden Variablen mit {{ variable }} ausgegeben und alle nicht existierenden (also auch Insert-Tags) werden stillschweigend entfernt.
Den Twig Syntax anpassen halte ich allerdings nicht für richtig (auch wenn es nahelegend wäre), aber dann würden Beispiele im Netz zu Twig nicht mehr im Contao Context passen und müssten immer angepasst werden.

Ich habe hierfür noch keine Lösung, aber ich arbeite dran ;-)

Replaces auf fertig generierten Ausgabecode?

Das generierte HTML läuft genau so durch den parseFrontendTemplate Hook, wie vorher auch.

Die derzeitigen Möglichkeiten bieten maximale Flexibilität.

Der Witz ist ja, dass eine Template Engine die gleiche und sogar höhere Flexibilität als Plain-PHP bietet.
Das Problem: Man muss es richtig anwenden können


Ich glaube ich fange mal an eine Wiki Seite dazu zu schreiben

[Psi]

Wieso glaubst du, dass du das nicht auch in einer Template-Engine ohne PHP schaffst?
Vielleicht geht es mit der Template Engine sogar einfacher, als in PHP, das ist nämlich ebenfalls Sinn einer Template Engine, Funktionen zu vereinfachen.

Natürlich schaffe ich das auch mit einer TPL-Engine, das hatte ich nie angezweifelt. Es geht einfach darum, dass ich nicht extra eine Funktion schreiben und registrieren will! Es finden sich immer Konstrukte die man mit native-Twig ohne Callback nicht umsetzen kann → siehe Christians Post.

Mit anderen Worten, ich will Twig mit PHP Support! Vllt nen Eval-Callback?

[tril]

Natürlich schaffe ich das auch mit einer TPL-Engine, das hatte ich nie angezweifelt. Es geht einfach darum, dass ich nicht extra eine Funktion schreiben und registrieren will! Es finden sich immer Konstrukte die man mit native-Twig ohne Callback nicht umsetzen kann → siehe Christians Post.

Ich schätze du hast meinen Post noch nicht gelesen gehabt, als du geschrieben hast
https://www.contao-community.de/show...l=1#post214746

Mit anderen Worten, ich will Twig mit PHP Support! Vllt nen Eval-Callback?

Du böser böser junge, du sollst doch nicht mit eval spielen *evil*

[leo]

Ähm, was ist so schlimm daran?
Dafür ist eine Template Engine doch da, man fügt ihr eigene Filter, Funktionen und Blöcke hinzu, wenn die build-in Fähigkeiten nicht ausreichen.

Bin 100% Deiner Meinung! Nur hätte ich für Contao 3 eine rückwärtskompatible Lösung gebraucht, weil die Templates bisher PHP verwenden und auch mit einer neuen Template-Engine funktionieren müssten.

[tril]

Bin 100% Deiner Meinung! Nur hätte ich für Contao 3 eine rückwärtskompatible Lösung gebraucht, weil die Templates bisher PHP verwenden und auch mit einer neuen Template-Engine funktionieren müssten.

Jup, da bin ich auch 100% deiner Meinung. (wow, ich sollte den Termin rot im Kalender anstreichen)

Deshalb denke ich dass der Feldversuch in einzelnen Extensions ganz sinnvoll ist, so dass wir für Contao Reloaded (oder was auch immer kommen wird) die nötige Erfahrung haben, wie wir Twig für den Einsatz in Contao anpassen müssen

[ixtensa]

Ich bin der Meinung, dass PHP eine gute Sprache ist um Templates aufzubauen. Wir setzen z.B. auch Oxid ein, welches ja Smarty benutzt. Ich kann nicht sagen, dass ich das übersichtlicher finde.

PHP hat davon abgesehen den Vorteil, dass sich ein Webentwicker damit gut auskennt und eben mal so eine oben genannte "Quick and dirty" Lösung einbauen kann, was ja immer wieder mal nötig ist.
Ich sehe keinen Grund Contao oder die Entwickler mit einer zusätzlichen Template-Engine zu belasten.

[Psi]

Nur noch ein kurzes Wort zu all denen die schon von Vorne herein auf "quick and dirty" pokern, das ist keine Software-Entwicklung und so was sollte nicht von vorne herein eine Möglichkeit sein. Wir wollen hier ja irgend wann mal eine professionelles Niveau erreichen und nicht immer so rumpfuschen.

Leo! Es geht keineswegs um öffentliche Programmierung, hier hat "quick and dirty" nichts verloren. Wohl aber bei diesen Low-Budget Projekten die man doch immer wieder für den Freund des Bekannten macht!

[joe]

Habt ihr euch mal die Smarty Extension http://www.contao.org/en/extension-l...000038.en.html angesehen?

{=$this->text;} 

Das sieht Kompatibel aus auf den ersten Blick oder übersehe ich da gerade was?

In Smarty (zumindest in Version 2) ist es zu dem möglich durch {php} tags eigenes php in den templates zu schreiben und zu verwenden.

[Psi]

So drüber nachgedacht und zu folgendem Schluß gekommen.
TwigPHP-Erweiterung was irgend ein evil-eval-php-tag in Smarty reinbaut. Wenn so komische Pfuscher like /me unbedingt dirty hacking betreiben wollen können sie die Erweiterung installieren und gut.

leoU, kompromiss?

[tril]

Für alle zum stöbern, ich habe zumindest mal die Grundlegenden Funktionen der Twig Integration dokumentiert:
http://de.contaowiki.org/Twig

Habt ihr euch mal die Smarty Extension http://www.contao.org/en/extension-l...000038.en.html angesehen?

Was es nicht alles gibt, die kannte ich noch gar nicht ... ich glaub ich muss mal Extension für Extension durch das ER gehen und mir alles anschauen, da kommen ja echte Schätze zum Vorschein

In Smarty (zumindest in Version 2) ist es zu dem möglich durch {php} tags eigenes php in den templates zu schreiben und zu verwenden.

Jau, das müsste bekannt sein
Aber ich sehe immer noch keine Notwendigkeit dafür.

So drüber nachgedacht und zu folgendem Schluß gekommen.
TwigPHP-Erweiterung was irgend ein evil-eval-php-tag in Smarty reinbaut. Wenn so komische Pfuscher like /me unbedingt dirty hacking betreiben wollen können sie die Erweiterung installieren und gut.

Wenn du es unbedingt haben willst, ich halte dich nicht auf

[andreas.schempp]

War die Anforderung mit PHP-Unterstützt nicht, dass es rückwärtskompatibel bleibt? Also bestehende Templates nicht angepasst werden müssen, aber neu die Engine zur Verfügung steht?

[tril]

[FLAMEMODE=on]

Ich bin der Meinung, dass PHP eine gute Sprache ist um Templates aufzubauen.

PHP ist aber eigentlich keine Templating-Sprache. Es ist eine embeded-ScriptSprache. Aber im Grunde hast du recht und ich glaube niemand hat was anderes behauptet

Wir setzen z.B. auch Oxid ein, welches ja Smarty benutzt. Ich kann nicht sagen, dass ich das übersichtlicher finde.

Smarty ist schon nicht schlecht, aber Twig ist noch Mächtiger und hat so tolle Konstrukte wie block womit sich Template Vererbungen realisieren lassen. http://twig.sensiolabs.org/doc/templ...te-inheritance
Außerdem orientiert sich Smarty leicht an der PHP Syntax, wodurch der Unterschied natürlich auch geringer ist, als von Twig zu PHP. s.a. https://www.contao-community.de/show...l=1#post214285

PHP hat davon abgesehen den Vorteil, dass sich ein Webentwicker damit gut auskennt und eben mal so eine oben genannte "Quick and dirty" Lösung einbauen kann, was ja immer wieder mal nötig ist.

Sry das ich das so sage, aber ich bin diese Argumentation langsam leid.
Das klingt immer so "nein, lass mir meine Technologien von 2000, ich will mit denen aus 2010 nichts zu tun haben".
Wer schlichtweg "zu faul" ist, sich mit aktuellen Technologien auseinander zu setzen, der sollte sich fragen ob er nicht den Beruf wechselt, weil in 2 Jahren kann er seinen Beruf sowieso nicht mehr ausführen weil er einfach nicht mehr auf dem aktuellen Stand ist.
Das mag jetzt hart klingen, aber so ist es halt. Template Engines sind keine "Hype" Technologie. Die gibt es schon seit vielen Jahren und sie haben sich etabliert. Es gibt sie in jeder Programmiersprache, einige Sprachen kommen effektiv gar nicht ohne aus, z.B. Perl oder J2EE (-> JSP). Selbst in JS wird regelmäßig Templating betrieben und andere Systeme sind keine Ausnahme. Sogar in PHP gab es mal die Diskussion eine "PHP Template Engine" einzuführen. Das zum Thema "PHP ist eine gute Sprache um Templates aufzubauen".

Nicht jeden dahergelaufenen PHP Entwickler muss in der Lage sein ein System "quick and dirty" anzupassen. Ich persönlich halte von Q&D sowieso nichts und versuche es soweit es geht zu vermeiden. In 99% der Fälle gelingt mir das auch, in dem ich mir einfach ein paar Helper-Klassen schreibe und somit das Template "sauber" halte, soweit dies möglich ist.

Und wie ich bereits hier https://www.contao-community.de/show...l=1#post214728 und hier https://www.contao-community.de/show...l=1#post214746 gezeigt habe. Eine Template Engine schränkt einen nicht in der Funktionalität ein, es ist sogar genau andersrum!


Ich gebe zu, nicht jede etablierte Technologie ist Sinnvoll, aber...

Ich sehe keinen Grund Contao oder die Entwickler mit einer zusätzlichen Template-Engine zu belasten.

Template Engines haben 2 große Vorteile:
1. Sie bieten mehr Funktionalität als PHP auf einfachere Art und Weise!
2. Sie sind sicherer als Plain PHP! http://twig.sensiolabs.org/doc/api.h...dbox-extension

Daher sehe ich eine Template Engine keineswegs als "Belastung" an.

[FLAMEMODE=off]

War die Anforderung mit PHP-Unterstützt nicht, dass es rückwärtskompatibel bleibt? Also bestehende Templates nicht angepasst werden müssen, aber neu die Engine zur Verfügung steht?

Ja und was willst du uns jetzt damit sagen?

[andreas.schempp]

Ja und was willst du uns jetzt damit sagen?

Ich hatte die Frage von Leo so verstanden, dass die bestehenden PHP-Tags in den Templates weiter funktionieren sollten, aber zusätzlich eine Template-Sprache benutzt werden kann. Damit wären alle bestehenden Templates rückwärtskompatibel.

[tril]

Ich hatte die Frage von Leo so verstanden, dass die bestehenden PHP-Tags in den Templates weiter funktionieren sollten, aber zusätzlich eine Template-Sprache benutzt werden kann. Damit wären alle bestehenden Templates rückwärtskompatibel.

Das ist ja auch richtig, deshalb können wir Twig ja auch nicht einsetzen, weil es PHP eben nicht unterstützt.

[andreasisaak]

War die Anforderung mit PHP-Unterstützt nicht, dass es rückwärtskompatibel bleibt? Also bestehende Templates nicht angepasst werden müssen, aber neu die Engine zur Verfügung steht?

Kommst du dann nicht in die Gefahr noch mehr Templates zu haben? xhtml/html5 und php/templateengine
Irgendwann wirds mir als Extension-Entwickler auch zuviel. Ja ich weiß, ich kann mich für php ODER die engine entscheiden aber manch einer entscheidet sich für was anderes und dann habe ich ne ziemlich wilde Installation. Wer will das alles noch pflegen?

Ich wäre dafür, es melden sich mal paar Leute die nicht nur Extensions programmieren sondern auch Installationen pflegen so richtig mit manuellen Updates oder der LiveUpdate ID etc etc.

[tril]

Kommst du dann nicht in die Gefahr noch mehr Templates zu haben? xhtml/html5 und php/templateengine

So betrachtet eigentlich nicht, die Idee wäre ja gewesen eine Template Engine langsam einzuführen, ohne das es zu Kompatibilitätsproblemen kommt, ergo dürften die Dateien auch nicht anders heißen.

Irgendwann wirds mir als Extension-Entwickler auch zuviel. Ja ich weiß, ich kann mich für php ODER die engine entscheiden aber manch einer entscheidet sich für was anderes und dann habe ich ne ziemlich wilde Installation. Wer will das alles noch pflegen?

Naja, praktisch betrachtet musst du dich eigentlich nur mit der Syntax auseinander setzen, mehr aber auch nicht.
Du hast entweder:
- template.html5 / template.xhtml für Templates mit PHP
oder
- template.html5.twig / template.xhtml.twig für Templates mit Twig

(die Smarty Extension ist viel zu alt und wird scheinbar nicht mehr gepflegt, fällt also vorerst raus)

Also so wirklich "wild" wird das nicht.

Ich wäre dafür, es melden sich mal paar Leute die nicht nur Extensions programmieren sondern auch Installationen pflegen so richtig mit manuellen Updates oder der LiveUpdate ID etc etc.

Hier, ich ich ... ach nee, ich hab ja keine LiveUpdate ID

[joe]

Zitat tristan

Smarty ist schon nicht schlecht, aber Twig ist noch Mächtiger und hat so tolle Konstrukte wie block womit sich Template Vererbungen realisieren lassen. http://twig.sensiolabs.org/doc/templ...te-inheritance
Außerdem orientiert sich Smarty leicht an der PHP Syntax, wodurch der Unterschied natürlich auch geringer ist, als von Twig zu PHP. s.a. https://www.contao-community.de/show...l=1#post214285

Naja Smarty 3 arbeitet auch mit Block Konstrukten, am besten mal Shopware ansehen da ist das ziemlich gut im Einsatz und macht echt Spaß. Ich war anfangs auch total begeistert von Twig, mittlerweile muss ich sagen das mir Smarty(gerade Smarty 3) mehr zusagt.

[tril]

Naja Smarty 3 arbeitet auch mit Block Konstrukten, am besten mal Shopware ansehen da ist das ziemlich gut im Einsatz und macht echt Spaß. Ich war anfangs auch total begeistert von Twig, mittlerweile muss ich sagen das mir Smarty(gerade Smarty 3) mehr zusagt.

I see, habe mich mit Smarty 3 nie wirklich auseinander gesetzt weil das für mich nie notwendig war.
Ich finde allerdings die Syntax von Twig etwas ansprechender.
Smarty verwendet block und /block,
Twig hingegen block und endblock.
Letzteres finde ich in einem von HTML überfluteten Template wo / gang und gebe ist besser zu lesen, weil es sich vom HTML absetzt.

Aber alles in allem hat sich die Smarty Syntax ja nicht verändert, so bleibt z.B. auch {assign name=X value=Y} bestehen.
Der Twig Pendant set lässt sich imo leichter lesen {% set X = Y %}
Ich denke, Twig hat was die Syntax angeht einfach den Vorteil, dass es jünger ist. Dafür kennt man den Smarty eher und er ist leichter weil er sich leicht am PHP Syntax orientiert.

Also das gleiche Problem wie immer, Geschmacks und Gewohnheitssache

[sandburg]

Das wäre jetzt für mich auch kein Grund wenn es nur das ist. Meine Meinung ist, dass du das entscheiden kannst wie du magst und wenn ich in Zukunft sagen kann "das CMS läuft dort nicht besorg dir einen richtigen Webspace" dann ist das schon Vorteil genug.
:-)

68 Beiträge und ich kann mich #9 nur anschließen - unser „Chef“ hat sich doch bereits entschieden ... oder?

Und wenn eine neue Template-Engine eingeführt wird, würde ich mir auch „Smarty 3“ wünschen!

VG - sandburg

[andreasisaak]

@sandburg

nein hat er nicht. sonst würde er nicht fragen.

[leo]

@sandburg Nein, das hat er nicht. Und es wird diese Änderung auch nicht geben, da sich die Mehrheit dagegen ausgesprochen hat.

[masterluc]

Hallo,

Das Thema dürfte ja durch sein, aber ich hab trotzdem lieber die Short Tags. Bei Templates funktionieren sie auch ohne Weiteres.

Leider kommt aber anscheinend readPhpFileWithoutTags damit nicht zurecht. Bei einer von mir entwickelten Erweiterung landete die config.php mit führendem "<?" mitten in der gecacheten config, was logischerweise das ganze System zum Abschmieren brachte. Natürlich habe ich den Fehler sofort gefunden und brav "<?php" hingeschrieben. Trotzdem: So etwas sollte eigentlich nicht passieren - der Code ist ja prinzipiell valide. Könnte man der Funktion nicht ein bissl Toleranz beibringen?

[tril]

Ich hoffe nicht, dass du "<?" wirklich verwendest, der steht bei PHP auf der Drop-List und wird in einer der kommenden Versionen vollständig entfernt.
Der "<?=" hingegen ist in PHP 5.4+ standardmäßig immer aktiv.

[stefan.sl]

Zum Thema Templateengine: wie sieht denn das mit der Performance aus, wenn man noch eine Template-Engine dahinter haut? Ist Twig genauso leicht verständlich, wie PHP? Wo ist der Mehrwert?

<?= fand ich früher immer gut, da es viel schneller geschrieben ist. Irgendwann wurde meines Wissens aber short_open_tag beim PHP-Paket unter Debian (oder allgemein) per default auf Off gesetzt. Ab da hab ich's mir abgewöhnt.

[tril]

<?= fand ich früher immer gut, da es viel schneller geschrieben ist. Irgendwann wurde meines Wissens aber short_open_tag beim PHP-Paket unter Debian (oder allgemein) per default auf Off gesetzt. Ab da hab ich's mir abgewöhnt.

Ja ist richtig, aber ab PHP 5.4 ist der <?= Tag aktiviert und lässt sich auch nicht deaktivieren.
Der short_open_tag beeinflusst nur noch den <? Tag und ist auch weiterhin standardmäßig deaktiviert.

[fiedsch]

Zum Thema Templateengine: wie sieht denn das mit der Performance aus, wenn man noch eine Template-Engine dahinter haut? Ist Twig genauso leicht verständlich, wie PHP? Wo ist der Mehrwert?

Twig kann den PHP Code, den es aus den Templates erstellt auch cachen. Dann sollte kein großer Performanceunterschied zu PHP-Templates bestehen.

Twig ist imho besser lesbar als PHP. Das wäre aus meiner Sicht einer der Pluspunkte. Aspekte wie Blöcke und damit Erweiterbarkeit von Templates wurden ja bereits angesprochen.

Es dürfte aber nichts geben, das ich mit Twig machen kann, in einem PHP-Template aber nicht, denn Twig erstellt ja letztlich auch nur PHP Code.

[tril]

Zum Thema Templateengine: wie sieht denn das mit der Performance aus, wenn man noch eine Template-Engine dahinter haut? Ist Twig genauso leicht verständlich, wie PHP? Wo ist der Mehrwert?

Twig und Smarty sind "kompilierende" Template Engines. D.h. die Engines überführen den jeweiligen Template Code in nativen PHP Code der ausgeführt wird. Dieser kompilierte PHP Code wird gecached und damit sind diese Engines genau so schnell wie natives PHP. Der Vorteil von Template Engines liegt vor allem im Funktionsumfang und dass die Syntax meist optimiert ist. Außerdem bieten Template Engines auch ein gewisses Sicherheitsfeature. So kann man halt nicht alles in Twig machen, was in PHP geht, auf der anderen Seite kann man aber auch komplexe Funktionen der Template Engine beibringen.
Im großen und ganzen sorgen Template Engines eigentlich dafür, dass man nicht mehr so viel in das Template "rotzt", was die Templates auch nach Jahren deutlich lesbarer macht.