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

In PHP 5.4 ist jetzt endlich "<?=" immer verfügbar, egal ob "short_open_tag" an oder aus ist. Es würde die Templates deutlich übersichtlicher machen, wenn wir das verwenden könnten. Einziger Nachteil: in PHP 5.3 muss dafür "short_open_tag" gesetzt sein.

Die Einstellung "short_open_tag" steht in PHP 5.3 auf "PHP_INI_PERDIR", kann also von überall aus gesetzt werden, außer aus dem Skript selbst mittels "ini_set()". Nun die Frage: Können wir verlangen, dass die Leute unter PHP 5.3 "short_open_tag" aktivieren?

(Eine Template-Engine wie Twig oder Smarty würde die Templates auch übersichtlicher machen, steht aber für Contao 3 nicht zur Diskussion. Die Twig-Syntax beißt sich außerdem mit der Inserttag-Syntax und Twig verarbeitet auch keinen PHP-Code, was wir für die Rückwärtskompatibilität bräuchten.)

Wo ist der Vorteil, ausser das Du pro PHP Datei mind. 2 Byte sparst ?

Ich glaub es geht garnicht ums einsparen, sondern wie Leo schon sagte um die Übersichtlichkeit.

Für meinen Teil würde ich mich dafür aussprechen es mit "<?=" zu machen. Da die Einstellung short_open_tag von jedem -leicht- gesetzt werden kann.

ist fuer mich persoenlich irgendwie kein Argument.

Ich sehe keine sonderlichen Mehrwert, wenn im Code

PHP-Code:

---

<?=

---

anstatt

PHP-Code:

---

<?php

---

steht.

<?= ersetzt nicht <?php sondern <?php echo

Ansonsten hättest du natürlich recht. Hier mal mehr Infos dazu
http://de.php.net/manual/de/ini.core...short-open-tag

Zitat:

---

Zitat von lindesbs

ist fuer mich persoenlich irgendwie kein Argument.

Ich sehe keine sonderlichen Mehrwert, wenn im Code

PHP-Code:

---

<?=

---

anstattt

PHP-Code:

---

<?php

---

steht.

---

Ich gebe Dir zwar recht, aber es ist wohl eher

PHP-Code:

---

<?=

---

anstattt

PHP-Code:

---

<?php echo

---

Bezüglich Lesbarkeit würde ich eher "ordentlich eingerückten Quelltext" begrüßen. Hier sind Templates manchmal etwas schwer zu lesen.

Also mein derzeitiger Provider hat das zwar "On" aber mit der Aussage "das kann ja jeder ändern" wäre ich vorsichtig.

Zitat:

---

Zitat von BugBuster

[…] aber mit der Aussage "das kann ja jeder ändern" wäre ich vorsichtig.

---

Jup. Ich habe das Problem zwar nicht, aber solange PHP 5.3 supported ist, würde ich das nicht ändern.

Zitat:

---

Zitat von leo

Es würde die Templates deutlich übersichtlicher machen, wenn wir das verwenden könnten.

---

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.
:-)

Zitat:

---

Zitat von leo

Die Twig-Syntax beißt sich außerdem mit der Inserttag-Syntax und Twig verarbeitet auch keinen PHP-Code, was wir für die Rückwärtskompatibilität bräuchten)

---

Naja, die Syntax von Twig lässt sich frei wählen!

Das mit dem PHP-Code bleibt... man könnte theoretisch schauen ob eine .html5 .xhtml Datei im Templateverzeichnis liegt und ansonsten die .twig.html5 nehmen :-)
Aber ich bin gegen so eine Lösung ;-) nicht noch mehr Dateiendungen.

Zitat:

---

Zitat von the_scrat

Ich glaub es geht garnicht ums einsparen, sondern wie Leo schon sagte um die Übersichtlichkeit.

---

Übersichlicher? Dieser "<?=" Tag? Wohl eher Gewohnheitssache.
Ich verwende ihn aus Prinzip nicht, weil mein Auge+Gehin auf "<?php" gepolt ist. Wenn der Tag "<?php=" heißen würde, wäre das was anderes :D
Also ich persönlich halte von den Short Tags recht wenig. Meiner Meinung nach führen Sie sogar zur Unübersichtlichkeit bei! Aber das ist meine persönliche Meinung.

Zitat:

---

Zitat von the_scrat

Da die Einstellung short_open_tag von jedem -leicht- gesetzt werden kann.

---

Noe, es gibt jede Menge Provider wo du es nicht kannst. Afaik geht es, bzw. ging es früher z.B. bei 1&1 und Strato nicht! Es wäre zu klären, ob das heute immer noch der Fall ist.

Ich kann nur sagen, das wir unser gemanagten Rootserver erst nach Diskussion von php5.2 auf php5.3 umgestellt bekommen haben bei hosteurope. Daher vertrete ich eher die Ansicht. Wir sollten ein Skrip bauen, das bei der Installation prüft welche php-version eingesetzt wird und dann anbietet die Templates zu optimieren. Das konnte dann ka Analog zu dem Kompriemierungsskript ablaufen. Bei Updates würde dann nicht nur die Datenbank geprüft, sondern auch die Templates, das ganze kann man über eine Variable in der Konfig steuern. Dann kann das jeder für sich entscheiden.

Also ich persönlich finde es nach einigen Vergleichen mit der aktuellen Syntax schon übersichtlicher. Jetzt wäre natürlich zu prüfen, ob es bei den diversen Hostern Probleme geben könnte.

Zitat:

---

Zitat von fiedsch

Bezüglich Lesbarkeit würde ich eher "ordentlich eingerückten Quelltext" begrüßen.

---

Da hätte ich auch nichts gegen.

Wäre halt eine Übergangslösung bis vielleicht in Contao Reloaded eine Template-Engine zum Einsatz kommt.
Von mir aus könnte man auch schon jetzt mit der Kompatibilität brechen, irgendwann muss man das sowieso.
(Ich finde besser früher als später.) Aber das ist ja schon entschieden.

Gibt's eine PSR-Meinung dazu? Ich persönlich bin eher dagegen.

PSR-1:

• Files MUST use only <?php and <?= tags.
• PHP code MUST use the long <?php ?> tags or the short-echo <?= ?> tags; it MUST NOT use the other tag variations.

Bin auch eher dagegen, keine ahnung wieso. aber wenn contao umsteigt dann bitte auch alle extensions. ein mischbetrieb ist nervig und löst verwirrung aus.

Kann ich gleich sagen, meine Erweiterungen werden NIE umsteigen auf short-tags.

Zitat:

---

Zitat von BugBuster

Kann ich gleich sagen, meine Erweiterungen werden NIE umsteigen auf short-tags.

---

dito

Zitat:

---

Zitat von andreasisaak

dito

---

Nun, hier geht es eher um den Coding Stil von Contao, was ihr in euren Erweiterungen macht ist ja eure Sache. Ich Code auch nicht PHP Code-Style konform :D

Zudem die Einsparung noch weiter geht, als bisher genannt:

PHP-Code:

---

<?= $name ?>

---

ersetzt

PHP-Code:

---

<?php echo $name; ?>

---

Das sind satte 8 Zeichen Einsparung pro Tag! Natürlich ist das Gewöhnungssache, aber ich habe jetzt bei einem Projekt damit gearbeitet und nach 2 Stunden fragt man sich, wieso man das nicht schon immer so gemacht hat. Denn die Templates sind auf einmal so übersichtlich.

Nebenbei bemerkt: Es hat schon einen Grund, warum "<?=" in PHP 5.4 zum immer verfügbaren, nicht mehr abschaltbaren Standard geworden ist :)

Wie ich bereits sagte, das ist reine Gewohnheitssache und ich verwende den Tag vorwiegend aus Gewohnheit nicht.
Aber wo wir gerade beim Thema "Übersichtlichkeit" sind, schaut euch mal den Vergleich an:

Original:

PHP-Code:

---

<?php $lang = $GLOBALS['TL_LANG']['tl_foo_bar']; ?>
<h1 id="tl_welcome"><?php echo $lang['headline']; ?></h1>

<div id="tl_soverview">

    <div id="tl_license">
        <h2><?php echo $lang['license']; ?></h2>

        <p><?php
            printf($lang['licensed'], 'Martin Mustermann', '01.12.2012');
            ?></p>
    </div>

    <div id="tl_statistic">
        <h2><?php echo $lang['statistic']; ?></h2>

        <table>
            <tr>
                <td colspan="3" class="total"><?php echo $this->totalCategoryCount; ?></td>
                <td><?php echo $lang['totalCategoryCount']; ?></td>
            </tr>
            <tr>
                <td class="published" title="<?php echo specialchars($lang['published']); ?>">
                    <?php echo $this->totalPublishedVehicleCount; ?>
                </td>
                <td>/</td>
                <td class="total" title="<?php echo specialchars($lang['total']); ?>">
                    <?php echo $this->totalVehicleCount; ?>
                </td>
                <td><?php echo $lang['totalVehicleCount']; ?></td>
            </tr>
            <?php foreach ($this->categoryVehicleCount as $count): ?>
            <tr<?php if (!$count['published']): ?> class="unpublished"<?php endif; ?>>
                <td class="published" title="<?php echo specialchars($lang['published']); ?>">
                    <?php echo $count['publishedVehicles']; ?>
                </td>
                <td>/</td>
                <td class="total" title="<?php echo specialchars($lang['total']); ?>">
                    <?php echo $count['vehicles']; ?>
                </td>
                <td><a href="contao/main.php?do=fahrzeugmanager_vehicle&amp;table=tl_fahrzeugmanager_vehicle&amp;id=<?php echo $count['id']; ?>"><?php printf($lang['categoryVehicleCount'], $count['category']); ?></a></td>
            </tr>
            <?php endforeach; ?>
        </table>
    </div>

    <div id="tl_moverview">
        <?php
        foreach ($GLOBALS['foo_bar'] as $group => $modules)
        {
            ?>

            <h2><?php echo $lang[$group]; ?></h2>

            <?php
            foreach ($modules as $module)
            {
                if ($module[0] == '!') {
                    $module = substr($module, 1);

                    ?>
                    <div class="tl_module_desc">
                        <h3><a style="color:#cfcfcf;" class="navigation <?php echo $module; ?>"><?php echo $lang[$module][0]; ?></a></h3>

                        <p><?php echo $lang[$module][1]; ?></p>
                    </div>
                    <?php
                }
                else {
                    ?>
                    <div class="tl_module_desc">
                        <h3><a href="contao/main.php?do=foo_bar&amp;table=tl_foo_bar_<?php echo $module; ?>" class="navigation <?php echo $module; ?>"><?php echo $lang[$module][0]; ?></a></h3>

                        <p><?php echo $lang[$module][1]; ?></p>
                    </div>
                    <?php
                }
            }
        }
        ?>
    </div>

</div>

---

Mit <?=

PHP-Code:

---

<?php $lang = $GLOBALS['TL_LANG']['tl_foo_bar']; ?>
<h1 id="tl_welcome"><?= $lang['headline']; ?></h1>

<div id="tl_soverview">

    <div id="tl_license">
        <h2><?= $lang['license']; ?></h2>

        <p><?php
            printf($lang['licensed'], 'Martin Mustermann', '01.12.2012');
            ?></p>
    </div>

    <div id="tl_statistic">
        <h2><?= $lang['statistic']; ?></h2>

        <table>
            <tr>
                <td colspan="3" class="total"><?= $this->totalCategoryCount; ?></td>
                <td><?= $lang['totalCategoryCount']; ?></td>
            </tr>
            <tr>
                <td class="published" title="<?= specialchars($lang['published']); ?>">
                    <?= $this->totalPublishedVehicleCount; ?>
                </td>
                <td>/</td>
                <td class="total" title="<?= specialchars($lang['total']); ?>">
                    <?= $this->totalVehicleCount; ?>
                </td>
                <td><?= $lang['totalVehicleCount']; ?></td>
            </tr>
            <?php foreach ($this->categoryVehicleCount as $count): ?>
            <tr<?php if (!$count['published']): ?> class="unpublished"<?php endif; ?>>
                <td class="published" title="<?= specialchars($lang['published']); ?>">
                    <?= $count['publishedVehicles']; ?>
                </td>
                <td>/</td>
                <td class="total" title="<?= specialchars($lang['total']); ?>">
                    <?= $count['vehicles']; ?>
                </td>
                <td><a href="contao/main.php?do=fahrzeugmanager_vehicle&amp;table=tl_fahrzeugmanager_vehicle&amp;id=<?= $count['id']; ?>"><?php printf($lang['categoryVehicleCount'], $count['category']); ?></a></td>
            </tr>
            <?php endforeach; ?>
        </table>
    </div>

    <div id="tl_moverview">
        <?php
        foreach ($GLOBALS['foo_bar'] as $group => $modules)
        {
            ?>

            <h2><?= $lang[$group]; ?></h2>

            <?php
            foreach ($modules as $module)
            {
                if ($module[0] == '!') {
                    $module = substr($module, 1);

                    ?>
                    <div class="tl_module_desc">
                        <h3><a style="color:#cfcfcf;" class="navigation <?= $module; ?>"><?= $lang[$module][0]; ?></a></h3>

                        <p><?= $lang[$module][1]; ?></p>
                    </div>
                    <?php
                }
                else {
                    ?>
                    <div class="tl_module_desc">
                        <h3><a href="contao/main.php?do=foo_bar&amp;table=tl_foo_bar_<?= $module; ?>" class="navigation <?= $module; ?>"><?= $lang[$module][0]; ?></a></h3>

                        <p><?= $lang[$module][1]; ?></p>
                    </div>
                    <?php
                }
            }
        }
        ?>
    </div>

</div>

---

Twig:

PHP-Code:

---

{% set lang = _lang.tl_foo_bar %}
<h1 id="tl_welcome">{{ lang.headline }}</h1>

<div id="tl_soverview">

    <div id="tl_license">
        <h2>{{ lang.license }}</h2>

        <p>{{ lang.licensed|format('Martin Mustermann', '01.12.2012')|raw }}</p>
    </div>

    <div id="tl_statistic">
        <h2>{{ lang.statistic }}</h2>

        <table>
            <tr>
                <td colspan="3" class="total">{{ totalCategoryCount }}</td>
                <td>{{ lang.totalCategoryCount }}</td>
            </tr>
            <tr>
                <td class="published" title="{{ lang.published }}">
                    {{ totalPublishedVehicleCount }}
                </td>
                <td>/</td>
                <td class="total" title="{{ lang.total }}">
                    {{ totalVehicleCount }}
                </td>
                <td>{{ lang.totalVehicleCount }}</td>
            </tr>
            {% for count in categoryVehicleCount %}
            <tr{% if not count.published %} class="unpublished"{% endif %}>
                <td class="published" title="{{ lang.published }}">
                    {{ count.publishedVehicles }}
                </td>
                <td>/</td>
                <td class="total" title="{{ lang.total }}">
                    {{ count.vehicles }}
                </td>
                <td><a href="contao/main.php?do=fahrzeugmanager_vehicle&amp;table=tl_fahrzeugmanager_vehicle&amp;id={{ count.id }}">
                    {{ lang.categoryVehicleCount|format(count.category) }}
                </a></td>
            </tr>
            {% endfor %}
        </table>
    </div>

    <div id="tl_moverview">
        {% for group, modules in settings %}

            <h2>{{ lang[group] }}</h2>

            {% for module in modules %}
                {% if module|slice(0,1) == '!' %}
                    {% set module = module|slice(1) %}

                    <div class="tl_module_desc">
                        <h3><a style="color:#cfcfcf;" class="navigation {{ module }}">{{ lang[module][0] }}</a></h3>

                        <p>{{ lang[module][1] }}</p>
                    </div>
                {% else %}
                    <div class="tl_module_desc">
                        <h3><a href="contao/main.php?do=foo_bar&amp;table=tl_foo_bar_{{ module }}" class="navigation {{ module }}">{{ lang[module][0] }}</a></h3>

                        <p>{{ lang[module][1] }}</p>
                    </div>
                {% endif %}
            {% endfor %}
        {% endfor %}
    </div>

</div> 


---

Gegenüber dem Twig Template finde ich sogar die PHP Variante mit <?= sehr unübersichtlich :cool:

Zitat:

---

Zitat von leo

Das sind satte 8 Zeichen Einsparung pro Tag!

---

Noe, nur 7 ^^

strlen("<?= ") -> 4
strlen("<?php echo ") -> 11

:p

Ein Semikolon gibt es auch noch. ;)

Das Semikolon kann man in beiden Varianten hinzufügen oder weg lassen, deshalb zählt es nicht :D

Zitat:

---

Zitat von leo.unglaub

Das einzige Ergebnis ist, dass man den Code schwerer lesen kann.

---

Ich sehe <?= weder, daß es den Code besser, noch , daß es den Code schlechter lesbar macht. Ist wohl hauptsächlich Geschmackssache.

Wenn ich es unbedingt "kurz" haben will

Code:

---

EXTENSION=xhtml
find -name *.${EXTENSION} | xargs sed -i -e"s/<?php echo /<?= /"

---

und wieder zurück mit

Code:

---

EXTENSION=xhtml
find -name *.${EXTENSION} | xargs sed -i -e"s/<?= /<?php echo /"

---

Zitat:

---

Zitat von leo.unglaub

* Tags die ich öffne schliese ich auch

---

Ich sehe nicht, wo das bei <?php echo vs <?php relevant wäre.

Zitat:

---

Zitat von leo.unglaub

* Code muss einfach lesbar sein

---

Vollkommene Zustimmung!

Wahllos herausgegriffenes Beispiel aus modules/calendar/cal_default.xhtml

# Original ...

PHP-Code:

---

<?php foreach ($this->days as $i=>$day): ?>
    <th class="label<?php if ($i == 0) echo ' weekend col_first'; if ($i == 6) echo ' weekend col_last'; ?>"><?php echo $day; ?></th>
<?php endforeach; ?>

---

# ... und "Fälschung"

PHP-Code:

---

<?php foreach ($this->days as $i=>$day): ?>
    <th class="label<?php if ($i == 0) echo ' weekend col_first'; if ($i == 6) echo ' weekend col_last'; ?>"><?= $day; ?></th>
<?php endforeach; ?>

---

# schöner (?) wäre etwas wie

PHP-Code:

---

<?php foreach ($this->days as $i=>$day): ?>
    switch ($i) {
        case 0:  $additional_css_classes = ' weekend col_first'; break;
        case 6:  $additional_css_classes = ' weekend col_last';  break;
        default: $additional_css_classes = '';
    }
    <th class="label<?php echo $additional_css_classes; ?>"><?php echo $day; ?></th>
<?php endforeach; ?>

---

weil das für mich auf einen Blick klar macht, was der Code erreichen will. Aber darüber kann man sicher endlos debattieren.

Ich bin ganz klar für die kurze Schreibweise, ist meiner Meinung nach viel übersichtlicher da die Variablen (im Editor mit Syntaxeinfärbung) viel besser sichtbar sind.

Hallo,

die persönlichen Vorlieben der Entwickler sehe ich eher als sekundär an. Auch ich müsste mich umstellen, würde das aber sicher auch tun. Ich sehe das eher wie einige Vorredner und betrachte die short-tags als Gewöhnungssache.

Als deutlich wichtiger empfinde ich, das man sicherstellen sollte, das Contao bei den meisten Hostern lauffähig bleibt. Wenn die aktuellen Voraussetzungen für das kommende Contao3 PHP5.3 ist, dann sollten wir vorerst auf die Umstellung auf short-tags verzichten. Wenn dann als Voraussetzung irgendwann PHP 5.4 oder höher kommt, würde ich es in Erwägung ziehen.

Viele Grüße
R.Fehrmann

@Leo also wenn du den wirklich einführen willst, dann stelle bitte sicher, dass für PHP 5.3 die Option short_open_tag aktiviert ist. Laut Doku lässt sich die Option immer setzen, also auch per ini_set.

Du musst also irgendwo in der Initialisierung das einbauen:

PHP-Code:

---

ini_set('short_open_tag', 1); 


---

Was haben aussagekräftige Methodenbezeichnungen mit dem short-tag in Templates zu tun?

Ich bin gegen short open tags.

Damit kann man keine xml Templates mehr bauen ohne ekelhaften workaround (da dann php versucht das tag <?xml zu interpretieren).
Ein

PHP-Code:

---

<?= "<?xml version=\"1.0\" />"; ?>
<?= $this->foo; ?>

---

empfindet hierbei wohl keiner als einfacher zu lesen als

PHP-Code:

---

<?xml version="1.0" />
<?php echo $this->foo; ?>

---

Zudem ich bei <?= nicht sicher sein kann, dass es nicht etwaig auf irgendeinen anderen praeprozessor trifft, welcher es interpretiert (analog asp_tags und mehrere apache module geladen).

Allgemein hab ich Bauchschmerzen mit den short tags, egal in welcher Variation, sei es nun <? oder auch <?=

Als weiteres Negativargument: Da muss man ja ggf. etliche Syntax-highlighter (u.a. hier im Forum) nachrysten damit der code yberhaupt noch als php erkennbar ist.

Zitat:

---

Zitat von xtra

Ich bin gegen short open tags.

Damit kann man keine xml Templates mehr bauen ohne ekelhaften workaround (da dann php versucht das tag <?xml zu interpretieren).
Ein

PHP-Code:

---

<?= "<?xml version=\"1.0\" />"; ?>
<?= $this->foo; ?>

---

empfindet hierbei wohl keiner als einfacher zu lesen als

PHP-Code:

---

<?xml version="1.0" />
<?php echo $this->foo; ?>

---

---

Das ist fast richtig, in PHP 5.4 würde das funktionieren solange short_open_tag=Off ist:

PHP-Code:

---

<?xml version="1.0" />
<?= echo $this->foo; ?>

---

In PHP 5.3 allerdings nicht, weil man dort <?= nur über die short_open_tag aktivieren kann.
Die anderen Argumente sind aber auch richtig. Vor allem das fehlende Syntax Highlighting im Forum und in anderen System nervt (meine IDE macht es zum Glück richtig :D)

Ich schaue bei sowas immer gerne nach links und rechts. Ich weiss das im Codeigniter Framework lange Zeit Short Tags in den Templates empfohlen wurde. Es wurde wieder zurück gerudert da es zu viele Probleme bei unterschiedlichen Hostern gab. Siehe Coding Standards: http://codeigniter.com/user_guide/ge...hort_open_tags

Genau die gleiche Gefahr sehe ich auch bei Contao. Ich denke das eine Template Engine der einzig vernünftige Weg ist und solange sollte man beim alt bewährten bleiben was auf den Unterschiedlichen Hosting Paketen auch funktioniert.

Zitat:

---

Zitat von leo.unglaub

Noch dazu kommt, dass falls Leute mit override_function() arbeiten ich mir nicht sicher bin, dass PHP dann die modifizierte echo version verwenden würde.

---

Aber... aber... aber.... echo ist doch gar keine function?

Zitat:

---

Zitat von xtra

Aber... aber... aber.... echo ist doch gar keine function?

---

Wie kommst du darauf?

Code:

---

$ php -r 'echo("foo");'
foo

---

Implementiert ist echo als Funktion und müsste sich mit override_function ersetzen lassen.
echo und print lässt sich nur zusätzlich als Sprachkonstrukt ohne () verwenden.

@tril: Leider ist short_open_tag in PHP 5.3 auf PHP_INI_PERDIR gesetzt, so dass es sich nicht über ini_set() setzen lässt. Sonst hätte ich gar nicht erst gefragt :)

Bezüglich Twig: Das Problem ist, dass Twig keinen PHP-Code parst. Fabien hat irgendwo sinngemäß mal geschrieben "never has, never will" und damit hat er ja auch Recht. Ansonsten wäre ich einer Umstellung auf Twig nicht abgeneigt gewesen.

Zitat:

---

Zitat von leo

@tril: Leider ist short_open_tag in PHP 5.3 auf PHP_INI_PERDIR gesetzt, so dass es sich nicht über ini_set() setzen lässt. Sonst hätte ich gar nicht erst gefragt :)

---

Ah ok, das ist in der Doku leider nicht so dokumentiert.

Zitat:

---

Zitat von leo

Bezüglich Twig: Das Problem ist, dass Twig keinen PHP-Code parst. Fabien hat irgendwo sinngemäß mal geschrieben "never has, never will" und damit hat er ja auch Recht. Ansonsten wäre ich einer Umstellung auf Twig nicht abgeneigt gewesen.

---

Ä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. Aber man verwendet kein PHP in einer Template Engine. Damit würde man die Template Engine ad absurdum führen...
Ich mache übrigens gerade den Feldversuch mit einer größeren Extension die ich aktuell entwickel, siehe hier https://github.com/InfinitySoft/contao-twig

MfG Tristan

Zitat:

---

Aber man verwendet kein PHP in einer Template Engine. Damit würde man die Template Engine ad absurdum führen...

---

Ich bin da etwas anderer Meinung!

* Ich verwende dann PHP im TPL wenn ich schnell einen kundenspezifischen Dirty-Hack brauch. Natürlich und diskussionsfrei ist das kein guter Stiel aber im Sinne von Preis/Leistung durchaus adäquat.

* Es gibt Logik die gehört in den View und NICHT in den Controller. Beispiel berechnete Attribute, Summenbildung, Datumsformatierungen ... Es ist einfach leichter im gewohnten PHP. Außerdem kann man hier sicher sein, dass man es umsetzten kann ohne eine Twig-Erweiterung.

→ Für mich wären Templates ohne PHP schmerzhaft, trotzdem werde ich mich Trils Twig Modul demnächst mal genauer ansehen ;)



<ontopic>Auf Short-Open-Tags würde ich verzichten, anscheinend sind sie doch nicht so unproblematisch einsetzbar. Und ganz ehrlich, die paar Zeichen mehr .... wayne</ontopic>

Zitat:

---

Zitat von Psi

* Ich verwende dann PHP im TPL wenn ich schnell einen kundenspezifischen Dirty-Hack brauch. Natürlich und diskussionsfrei ist das kein guter Stiel aber im Sinne von Preis/Leistung durchaus adäquat.

---

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.

Zitat:

---

Zitat von Psi

* Es gibt Logik die gehört in den View und NICHT in den Controller. Beispiel berechnete Attribute, ...

---

Berechnete Attribute? Meinst du sowas:
{% set friendlyEmail = firstname ~ " " ~ lastname ~ " <" ~ email ~ ">" %} ?

Zitat:

---

Zitat von Psi

... Summenbildung, ...

---

und sowas:
{% set sum = var1 + var2 + var3 %}

Zitat:

---

Zitat von Psi

Datumsformatierungen ...

---

und sowas:
{{ timestamp|dateFormat }}
{{ timestamp|datimFormat }}
(die zwei Filter stammen aus meiner Twig Erweiterung)

oder Twig nativ:
{{ timestamp|date('H:i:s') }}

Zitat:

---

Zitat von Psi

Es ist einfach leichter im gewohnten PHP.

---

Ich behaupte, das ist ein Irrglaube, resultierend daraus das du Twig zu wenig kennst :)

Zitat:

---

Zitat von Psi

Außerdem kann man hier sicher sein, dass man es umsetzten kann ohne eine Twig-Erweiterung.

---

Du musst ja noch nicht mal immer eine Twig Erweiterung schreiben, es reicht wenn du die Funktion schreibst und registrierst. http://twig.sensiolabs.org/doc/advanced.html

Zitat:

---

Zitat von Psi

→ ..., trotzdem werde ich mich Trils Twig Modul demnächst mal genauer ansehen ;)

---

Will ich doch hoffen, ich Erweitere die Integration aktuell auch hier und da immer wieder, um einfach den Anforderungen im Contao Context gerecht zu werden ;)

Ich bin halt aufgrund meiner Vergangenheit von Smarty noch angehaucht und überzeugt, man konnte mit Smarty schon sehr viel machen und mit Twig noch mehr :D

*Thread gekapert*

Mir scheinen die Nachteile der Short Tags größer zu sein als die Vorteile - von daher würde ich das nicht gerne ändern.

Templates ohne PHP fände ich auch sehr schmerzhaft. Sicher, man kann andere Konstrukte nutzen (siehe oben), aber ob man damit immer alles abbilden kann, was man über PHP kann..... Zweifel. Datenbankabfragen? Includes? Abgeänderte Inserttags? Replaces auf fertig generierten Ausgabecode? Alles Sachen, die man oft braucht, wenn eben keine Extension dafür geschrieben/bezahlt werden muss/soll. Die derzeitigen Möglichkeiten bieten maximale Flexibilität. Würde das irgendwann wegfallen, würde Contao eines der Hauptargumente für seinen Einsatz "wegverbessern". Aber soweit sind wir ja noch nicht ;)

Grüße,

Christian

Zitat:

---

Zitat von christian

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.

Zitat:

---

Zitat von christian

Datenbankabfragen?

---

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

HTML-Code:

---

{% 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")

Zitat:

---

Zitat von christian

Includes?

---

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

Zitat:

---

Zitat von christian

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 ;-)

Zitat:

---

Zitat von christian

Replaces auf fertig generierten Ausgabecode?

---

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

Zitat:

---

Zitat von christian

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 :)

Zitat:

---

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? :rolleyes:

Zitat:

---

Zitat von Psi

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

Zitat:

---

Zitat von Psi

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

---

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

Zitat:

---

Zitat von tril

Ä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.

Zitat:

---

Zitat von leo

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) :D

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 :)

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.

Zitat:

---

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!

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

PHP-Code:

---

{=$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.

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? :rolleyes:

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

Zitat:

---

Zitat von joe

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 :eek:

Zitat:

---

Zitat von joe

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.

Zitat:

---

Zitat von 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.

---

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

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?

[FLAMEMODE=on]

Zitat:

---

Zitat von ixtensa

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 :)

Zitat:

---

Zitat von ixtensa

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

Zitat:

---

Zitat von ixtensa

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...

Zitat:

---

Zitat von ixtensa

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]

Zitat:

---

Zitat von 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?

---

Ja und was willst du uns jetzt damit sagen? :confused:

Zitat:

---

Zitat von tril

Ja und was willst du uns jetzt damit sagen? :confused:

---

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.

Zitat:

---

Zitat von andreas.schempp

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.

Zitat:

---

Zitat von 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?

---

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.

Zitat:

---

Zitat von andreasisaak

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.

Zitat:

---

Zitat von andreasisaak

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. :)

Zitat:

---

Zitat von andreasisaak

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 :D

Zitat tristan

Zitat:

---

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.

Zitat:

---

Zitat von joe

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 ;)

Zitat:

---

Zitat von psren

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

@sandburg

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

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

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?

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.

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.

Zitat:

---

Zitat von stefan.sl

<?= 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.

Zitat:

---

Zitat von 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?

---

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.

Zitat:

---

Zitat von 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?

---

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.