[trefixxx]

Hallo zusammen,
ich bin über einen Link in einem anderen Forum hier hereingeschneit und es gefällt mir richtig gut

Aber komme ich am Besten direkt zu meiner Frage:
Und zwar geschäftige ich mich gerade mit PHP Patterns (mit dem Buch aus dem O'Reilly Verlag von Hr. Schmidt) und möchte meine Website mit Templates (natürlich mit einer Templateklasse) aufbauen (euer Tutorial habe ich mir auch schon angeschaut).

1) Templateklasse:
Viele behaupten, dass Templatefunktionen wie {$foo} unnötig sind, man könne direkt <?=$foo ?> schreiben. Was ist daran? Was ist besser?

2) Funktion von Tempalte-Managing:
Außerdem möchte ich, wie in Wordpress, im Backend einzelne Seiten erstellen können. Die Funktionsweise ist klar. Einfach eine neue php-Datei aufrufen (in WP ist das ja die single.php), die den angefragten Seitenname in der Datenbank sucht und dazu den passenden Seiteninhalt ausgibt.
Wie aber kann ich die Seitenstruktur individuell bestimmen? In Wordpress-Backend kann man ja spezielle Templates anfügen. Wie funktioniert das System dahinter?

Wär super, wenn ihr euch dazu äußern könntet.
Vielen Dank

[robo47]

zu 1)
Es kommt drauf an was man will, man kann auch php für seine Templates nutzen, damit ist man was funktionalität angeht unschlagbar, aber der Nachteil kann sein, dass z.b. ein kleiner Fehler im Template schon zu Problemen führt, weil ne Klammer vergessen wurde und somit ein parse-error auftritt und das wars dann mit der Seitenausführung. Ausserdem ist es wenn das System auch Leute einsetzen die kein PHP können oftmals einfacher eine einfache template-syntax zu nutzen (wie beispielsweise smarty oder ähnliches)

übrigends: <?=$foo ?> kann ein Problem darstellen, wenn die php-option short_tags deaktiviert ist und <?php= geht meines Wissens nach nicht.

zu 2) kann ich nichts sagen, da ich mich mit Wordpress überhaupt nicht auskenne.

[trefixxx]

Das kann ich natürlich auch Wordpress-unabhängig formulieren.

Und zwar möchte ich erreichen, dass ich verschiedene seiten erstellen kann und auf eine weise wie www.seite.de/seite1 aufrufen kann (mit .htaccess und mod_rewrite).
Das Problem: Bestimmte seiten sollen ein spezielles template zugewiesen bekommen. wie erreiche ich das?

[bobby]

Hi trefixxx,

ich könnte mir das so vorstellen (auch ich habe noch nie wordpress benutzt) :

In der Datenbank steht, dass Seite1 dem Template 'grün' zugewiesen ist. Also schaut deine aufgerufene PHP-Datei (single.php) nach, ob es das Template 'grün' finden kann und öffnet diese, befüllt es mit Inhalten und schickt es an den Browser.

Vorraussetzung ist natürlich das alle Templates die gleichen Platzhalter benutzen.

Kein großer Zauber.

bobby.

[kampfgnom]

letzten endes wird mit Wordpress sicher auch nichts anderes gemacht als

www.example.tld/testseite/ nach www.example.tld/index.php?p=testseite weiterzuleiten!

und man hatt vorher verschiedene Templates die danach mit inhalt befüllt werden (s.bobby)

eigentlich nich schwer =)

[MrNiceGuy]

Zitat von robo47

zu 1)
Es kommt drauf an was man will, man kann auch php für seine Templates nutzen, damit ist man was funktionalität angeht unschlagbar, aber der Nachteil kann sein, dass z.b. ein kleiner Fehler im Template schon zu Problemen führt, weil ne Klammer vergessen wurde und somit ein parse-error auftritt und das wars dann mit der Seitenausführung. Ausserdem ist es wenn das System auch Leute einsetzen die kein PHP können oftmals einfacher eine einfache template-syntax zu nutzen (wie beispielsweise smarty oder ähnliches)

Es widerspricht aber jeglicher Logik, Templates (!!! *explizitaufdasWort"Template"hinweis* !!!) zu verwenden, wenn man dann letztendlich doch PHP-Code verwendet, um die Daten im Template anzeigen zu lassen. Templates sind ja gerade dazu gedacht, den Code vom Layout zu trennen, aber es reicht nicht einfach eine Datei zu erstellen, in der dann nur das Layout zusammengekleistert wird, wenn es denn immernoch PHP enthält.

Abgesehen davon ist es schon richtig, dass die Syntax eine entscheidende Rolle spielt, aber dass gerade Smarty als Beispiel genannt wurde ist wohl eher auch nicht so toll, denn bevor ich die Syntax von Smarty erlernt habe, kann ich auch eben schnell direkten PHP-Code schreiben. Entweder man nutzt etwas wirklich einfaches oder lässt es gans. Meiner Meinung nach sollte ein Template-System ohnehin nicht mehr als folgende Elemente zur Ausgabesteuerung enthalten:

- Ausgabe von Zeichenketten, Zahlen und Datum/Uhrzeit (sind die 3 kleinsten "Informationseinheiten" einer Webseite)
- Schleifen zur Ausgabe von Listen (usw.)
- Simple Bedingungen (Mehr als ein "Zeige dies an, wenn Platzhalter xy (nicht) leer ist" sollte nicht sein!)

Viel mehr sollte ein Template-System meiner Meinung nach nicht enthalten. Einzige Ausnahme würde ich vielleicht noch für administrative Links und Seitennavigation machen, damit diese nicht jedes Mal im Code generiert werden müssen, aber das bleibt ja jedem selbst überlassen.

[pmayer]

Ich verwende PHP als Template Sprache. Variablen weiße ich meiner View Komponente via $view->variable (dass __get überschreibt) oder über assign (key, value). das template wird via require eingebunden und ich kann über $this->templateVariable auf die gesetzten variablen zugreifen.
In meinen templates verwende ich schleifen, bedingungen, instanziere objekte (hauptsächlich view helper) und rufe dann deren methoden auf. Es kann auch vorkommen, dass ich queries gleich in das template schreibe (also zur ausgabe), weil es ja keinen sinn macht im controller daten fürs template aus der datenbank oder von wo auch immer zu lesen. Nur meine BL is in den Controlleren.

Von Template Systemen halte ich deshalb nichts, weil es nur noch eine ünnötige Schicht zwischen Applikation und Templates ist. Sie machen eigentlich alles nur komplizierter und langsamer.

MfG Peter

[Basti]

Zitat von MrNiceGuy

Es widerspricht aber jeglicher Logik, Templates (!!! *explizitaufdasWort"Template"hinweis* !!!) zu verwenden, wenn man dann letztendlich doch PHP-Code verwendet, um die Daten im Template anzeigen zu lassen. Templates sind ja gerade dazu gedacht, den Code vom Layout zu trennen, aber es reicht nicht einfach eine Datei zu erstellen, in der dann nur das Layout zusammengekleistert wird, wenn es denn immernoch PHP enthält.

Nein, hier möchte ich ebenfalls widersprechen. PHP ist ja bereits eine Template-Sprache, die man einfach in HTML einbetten kann und es geht hier nicht um die Trennung von Code und Layout, sondern um die Trennung von Geschäfts- und Darstellungslogik.

Und hier ist dann auch das Problem. In der Regel möchte man sicherstellen, dass ein Templatedesigner

1. nur auf bestimmte Daten Zugriff hat,
2. nur lesend auf diese Daten zugreift und ev. auch noch
3. sich alle verfügbaren Daten anzeigen lassen kann.

Das lässt sich natürlich nicht umsetzen, wenn der Designer einfach PHP-Templates erstellt, sondern dazu braucht es entweder eine andere Template-Sprache, oder PHP muss selbst irgendwie gefiltert werden, was ich aber noch niemanden hab wirklich umsetzen sehen.

Solange das aber keine Anforderung an das System ist, dass da ein
Templatedesigner nichts kaputt machen darf kannst du dir natürlich eine Template-Engine sparen.

Ich hab z.B. ein umfangreiches CMS entwickelt, das bislang noch keine TE besitzt, da ich der einzige bin, der die Vorlagen von den Designern umsetzt wenn es über css-Anpassungen hinaus geht.

Ein weiteres Argument pro TE ist die Schreibfaulheit. Ein Widget z.B. muss ich im Template immer erst bauen, vor dem Iterieren über bestimmte Werte muss erst geprüft werden, ob die werte zulässig sind etc. Dafür benutze ich zwar auch einfache Methoden, aber mit einer Template-Sprache ist man damit natürlich flotter und kann intern auch so einiges umbauen, ohne an die Templates zu müssen.

Weiter will ich dir ans Herz legen, Templates nicht in PHP durchzuarbeiten, sondern einfach in PHP zu übersetzen, wie das z.B. Smarty macht. Ich hab hier Ansätze einer TE, in der ich mit einem XSLT XML-Templates in PHP umschreibe. Hier hab ich dann auch gleich die gewähr, dass das HTML in sich "geschlossen" ist.

Zu der Frage (oder dem Statement) zu den sinnvollen Template-Features würde ich schon noch ein paar hinzufügen. Modifikatoren sind z.B. schon eine feine Sache, deren Vorhandensein die Genervtheit der Programmierer auf die Template-Designer deutlich senkt.

Weiter sollten bestimmte Funktionen und globale Werte vorhanden sein. Ich denke da vor allem an Zeit- und Datums-Funktionen.

Widgets hab ich bereits erwähnt. Das könnten z.B. auch "Untertemplates" ohne Controller sein (Bild, Link, …-), aber ggf. auch komplexere Gebilde, wie vom Benutzer interaktiv sortierbare Tabellen, Registerkarten, oder sonstige Blöcke, die man weg- und herklicken kann etc.

Eine weitere Anforderung könnte eine Schnittstelle für die internationalisierung von Inhalten sein.

Basti

[MrNiceGuy]

Quelle: Wikipedia

http://de.wikipedia.org/wiki/Template

[...] in der Programmierung von Webanwendungen (etwa mit PHP, Perl, ASP, Python) eine Technik zur Trennung von Programm-Code und Design [...]

Und das wurde auch bisher überall so beschrieben, wo ich zu dem Thema was gelesen habe.

Die Erweiterungen, wie du sie beschreibst sind meines Erachtens nach auch mit meinen oben genannten "Einschränkungen" ohne große Probleme umsetzbar. Die kleinsten Informationseinheiten bleiben nunmal Zeichenketten, Zahlen und Datum/Uhrzeit. Andere Inhalte gibt es schlichtweg nicht.

Und @pmayer: Erkläre mir bitte mal sinnvoll, wozu die "Trennung" (die ja nicht vorhanden ist) nötig ist? Dann kannst du doch gleich alles ins "Template" schreiben an PHP-Code, wenn du eh schon Datenbank-Abfrage, Instanzierungen usw. im Template selber durchführst, da es im Script ja anscheinend nichts zu suchen hat!?

EDIT: Einen habe ich noch: Es ist ja schön und gut, wenn man es in PHP übersetzt, wie es Smarty tut und es ist auch toll, wenn das alles so funktioniert, aber es ist nicht so toll, wenn man sich vor Augen hält, dass dafür entweder eval() oder ein Include genutzt werden muss. Das setzt wieder voraus, dass man eine weitere Absicherung einbaut, damit kein Fremdcode eingeschleust werden kann.

[Basti]

Zitat von MrNiceGuy

Quelle: Wikipedia

http://de.wikipedia.org/wiki/Template

Und das wurde auch bisher überall so beschrieben, wo ich zu dem Thema was gelesen habe.

Die Frage ist halt, wie man "Design" hier definiert. Wenn du sagst, es gehört zum "Design", dass z.B. in einer Tabelle alle Spalten abwechselnd dargestellt werden sollen, dann stimme ich dir zu. Aber genau das ist eben auch "Programm-Code", eben Darstellungs-Logik. Dazu gehört auch, dass z.B. diese Tabelle nur 10 Einträge enthalten darf, man sich durch die einzelnen Seiten durchblättern kann und die Pfeile ausgegraut sind, wenn es nichts zu blättern gibt. Das ist alles "Programm-Code".

In sofern ist die Sichtweise, es wird Code von Design getrennt einfach verkürzt und auf diesen Punkt wird immer wieder hingewiesen, dass die Trennlinie nicht darin liegt, ob hier etwas "programmiert" und dort etwas "gestaltet" wird, sondern ob die Programmierung hier die Daten verarbeitet oder dort die Darstellungslokgik umsetzt.

Und zu lesen gibt es darüber genug. Kannst ja, um beim Medium zu bleiben einfach mal in den englischsprachigen Wikipedia-Artikel schauen oder nach "separation pesentation business logic" googlen.

Und @pmayer: Erkläre mir bitte mal sinnvoll, wozu die "Trennung" (die ja nicht vorhanden ist) nötig ist? Dann kannst du doch gleich alles ins "Template" schreiben an PHP-Code, wenn du eh schon Datenbank-Abfrage, Instanzierungen usw. im Template selber durchführst, da es im Script ja anscheinend nichts zu suchen hat!?

Einfach mal z.B. in MVC und dessen unterschiedliche Interpretationen und Varianten einlesen. Im Web greift die View-Komponente oft nur auf die Daten zu, die ihnen die Controller direkt zur Verfügung gestellt haben ($View->assign('username', 'Paul')), im Ursprung greift die View jedoch direkt auf die Model-Schicht zu und wird von den Controllern allenfalls über Änderungen informiert.

Bei Ajax-Geschichten oder Frameworks wie Prado kann sowas dann auch in der Fire-and-Forget-Welt von PHP wieder relevant werden. Aber auch darüber hinaus ist der Ansatz, aus der View heraus direkt lesend auf die DB zuzugreifen natürlich nicht zu verachten, denn er kann eine Anwendung natürlich sehr entlasten und flott machen.

EDIT: Einen habe ich noch: Es ist ja schön und gut, wenn man es in PHP übersetzt, wie es Smarty tut und es ist auch toll, wenn das alles so funktioniert, aber es ist nicht so toll, wenn man sich vor Augen hält, dass dafür entweder eval() oder ein Include genutzt werden muss. Das setzt wieder voraus, dass man eine weitere Absicherung einbaut, damit kein Fremdcode eingeschleust werden kann.

Ich benutze weder eval() noch include(), sondern einfach XSLT. Hier wird z.B. aus einem:

<ul foreach="menu" as="entry">
    <li><textlink url="entry.url" text="entry.title" /></li>
</ul> 

ein:

PHP-Code:

<?php
if ($this->isIterable('menu')) {
?>
<ul>
<?php
    $Ns = $this->getNamespace();
    $sVarname = $Ns->getVarname();
    foreach ($this->getVar('menu') as $$sVarname) {

        $Ns->register($sVarname, 'entry');
?>
        <li><?php

$Link = $this->createWidget('textlink', array('url' => 'entry.url', 'text' => 'entry.title'));
$Link->display();

?></li>

<?php
    }
    $this->dropNamepace($sNs);
?>
</ul>
<?php
}

So, mal gerade aus dem Bauch. Ich hab schon lange nicht mehr dran gesessen. Da gibt es kein "Code einschläusen". Natürlich ist das ziemlich frickelig und da schleicht sich schnell ein Fehler ein, aber hast du dir schonmal die Threads hier angeschaut, wo Leute mit regulären Ausdrücken versuchen, verschachtelte Schleifen aufzudröseln? Das ist auch kein Vergnügen und der Prozess ist nicht zu cachen (es sei denn, die Daten bleiben unverändert natürlich).


Basti

[MrNiceGuy]

OK, wir haben unterschiedliche Standpunkte über die Definition von Code und Design. Für mich ist Code alles, was zu PHP gehört und Design alles, was zu HTML gehört. Scheißegal, ob eine Schleife nun lediglich HTML-Teile widerholt oder Datenbankergebnisse durchläuft. Wir werden da also auf keinen grünen Zweig kommen, aber das macht auch nichts, denn letztendlich kann ja doch jeder machen, was er will Ich finde halt einfach, dass das nicht gemischt werden sollte (PHP und HTML), auch wenn es ursprünglich dazu gedacht war.

Es ging mir nicht um die Trenning in $View, sondern in die Trennung, die angeblich stattfinden soll zwischen dem eigentlichen Code und dem "Template", was ja aber auch nur ein PHP-Script mit untergemischtem HTML ist, ist!? Ich sehe keinen Vorteil darin dann aus dem Script (zum Beispiel) 2 Dateien zu machen. Diese Trennung ist in meinen Augen mehr als unlogisch oder hat das andere Hintergründe?

Du bindest das generierte PHP dann ohne eval() oder include() ein? Das wüsste ich gerne, wie du das machst O_o

[$traight-$hoota]

natürlich muss jeder php code irgendwie eingebunden werden (geht aber auch ohne eval() und include( per require() *SCNR*). Aber die Möglichkeit, Fremdcode einzuschleusen ist dafür eigentlich genau so groß, wie für feste Programmteile. Die gecachten Templates sind nämlich genauso zugänglich (über FTP o.ä.) wie persistente Scripte. Da sollte kein vergrößertes Risiko dabei sein.

Ich verstehe das MVC-Prinzip ähnlich wie Basti, aber dabei gibt es oftmals das Problem, dass in der Darstellungslogik noch zu viel programmiertechnisches drinsteckt und die Designer überfordert. Nach der Definition "Code und Design getrennt" ist es da schon besser, dass der eine Teil von Programmierern erledigt wird und um die Darstellung können sich dann Designer kümmern, die außer HTML nur noch template-variablen und ggf. -schleifen kennen müssen.
Mögliche Lösungen dafür sind entweder die View nochmal in Darstellungslogik und Design zu trennen oder von den Designern eben noch mehr Programmierwissen zu verlangen. Das muss ja nicht in PHP oder so sein, wie man z.B. an Bastis XML-templates sehen kann.
Würde mich aber mal interessieren, wie viel "Logik" man damit umsetzen kann. Und auch generell finde ich diese XSLT-geschichte ganz praktisch und weitaus besser als Templatesysteme, die das Model als XML mit nem XSLT transformen und dann daraus den HTML-Code liefern.

[Ben]

Ich finde, dass sind irgendwie Diskussionen zu "Glaubensfragen" und somit endlos.

Ich muss gestehen, dass ich die Arbeit mit z.B. Smarty einfach übersichtlicher finde. Trennung Code, Design .. hm, mir geht es eher darum, dass ich kein PHP-Elemente in den Template-Dateien habe. Durch gezieltes Caching sollten auch die eventuell auftretenden Performance-Unterschiede, die sowieso nur bei hoch frequentierten Seiten zum Tragen kommen, wieder wett gemacht werden können.

[Basti]

Zitat von MrNiceGuy

OK, wir haben unterschiedliche Standpunkte über die Definition von Code und Design. Für mich ist Code alles, was zu PHP gehört und Design alles, was zu HTML gehört. Scheißegal, ob eine Schleife nun lediglich HTML-Teile widerholt oder Datenbankergebnisse durchläuft. Wir werden da also auf keinen grünen Zweig kommen, aber das macht auch nichts, denn letztendlich kann ja doch jeder machen, was er will Ich finde halt einfach, dass das nicht gemischt werden sollte (PHP und HTML), auch wenn es ursprünglich dazu gedacht war.

Das sind dann aber zwei paar Stiefel. Das eine ist das Prinzip der Trennung von … du nennst es Code und Design, ich nenne es Geschäfts- und Darstellungslogik (ich glaube, wir meinen das Gleiche). Das andere ist die Frage, wie ich die Darstellungslogik implementiere. Dazu benutzt der eine Smarty, der andere XSLT, der nächste eben PHP.

Es macht in meinen Augen wenig Sinn zu sagen: Diesen oder jenen Weg sollte man nicht gehen. Jeder Weg, jede Technologie hat ihre Vor- und Nachteile. PHP hat die Vorteile, dass es keine spezielle Template-Engine braucht, dass es unglaublich mächtig ist (in dem Kontext allemal) und dass es schnell ist. Weiter auch, dass keine weitere "Sprache", wie z.B. die Smarty-Syntax gelernt werden muss bzw. umgekehrt, dass man, wenn mann PHP für den Gebrauch in Templates lernt, dieses Wissen dann eben auch in anderem Zusammenhang nutzen kann. Nachteile sind ganz klar, dass der Template-Programmierer hier so ziemlich den vollen Zugriff auf das System hat. Er kann Daten manipulieren, nötige Objekte löschen, kann Sessions verheizen oder Sicherheitslöcher einbauen, kann Fehler produzieren oder den Server killen. Das wird er wohl nicht versuchen, warum auch, aber da er die Möglichkeit hat, muss er die Disziplin und das Know How aufbringen, hier eben nichts falsch zu machen.

Wenn der Punkt gegeben ist (und das ist er bei mir z.B.), dann spricht doch nichts gegen die Verwendung von PHP, um eine Schleife in ein HTML-Template zu bringen.

Es ging mir nicht um die Trenning in $View, sondern in die Trennung, die angeblich stattfinden soll zwischen dem eigentlichen Code und dem "Template", was ja aber auch nur ein PHP-Script mit untergemischtem HTML ist, ist!? Ich sehe keinen Vorteil darin dann aus dem Script (zum Beispiel) 2 Dateien zu machen. Diese Trennung ist in meinen Augen mehr als unlogisch oder hat das andere Hintergründe?

Diese Trennung macht absolut Sinn. Schau dir mal folgendes ganz banales, nicht objektorientiertes Beispiel an:

PHP-Code:

<?php

inlude('config.php');
inlude('undo_magic_quotes.php');

$aViewVars = array();


include('guestbook_lib.php');

if (isset($_POST['guestbook'])) {

    $aRequest = $_POST['guestbook'];
    if (guestbook_entryValid($_POST['guestbook'])) {

        guestbook_addEntry($_POST['guestbook']);
        $sView  = 'guestbook/display_entries';
        $sMsgId = 'guestbook_add_success';

    } else {

        $sView     = 'guestbook/add';
        $aViewVars = $_POST['guestbook'];
        $sMsgId    = 'guestbook_add_invalid';
    }

} else if (isset($_GET['add'])) {

    $sView = 'guestbook/add';
}

include($sView . '.php');

Das Beispiel ist natürlich schwer vereinfacht (natürlich wäre hier bei Erfolg eine Weiterleitung angebracht etc.), aber das sei nun mal der Code für ein Gästebuch-Modul. Die "Sicht" guestbook/add wird an zwei Stellen, in Abhängigkeit von den Eingaben des Benutzers eingebunden. Das passiert ständig, daher macht es Sinn, diese Sicht da auszuklammern und das logischerweise in eine andere Datei. Welche Technik dann benutzt wird, um die Inhalte (hier $aViewVars und $sMsgId) in die Vorlage zu bringen das ist ein ganz anderer Stiefel.

Wichtig bzw. sinnvoll ist eben die klare Aufgabenteilung: Im einen Programmblock wird der Ablauf einer bestimmten Aktion beschrieben. Dort wird auch entschieden, welche Sicht der Benutzer zu Gesicht bekommt und Daten werden ggf. verändert und womöglich (wie hier und auch sonst fast in jeder Webanwendung) an die View übergeben (hier einfach durch das globale Array $aViewVars). Eine andere Komponente kennt die Datenbank und kann Datensätze überprüfen, auslesen, verändern, hinzufügen und löschen. Die dritte Komponente ist für die Darstellung der Inhalte zuständig.

Diese Aufteilung macht einfach Sinn und wenn man sich entscheidet, keine Template Engine einzusetzen, dann ist man gut beraten, sich dennoch an diese Aufteilung zu halten. Das ist einfach ein Entwurfsprinzip, das, bis auf die genannten Variationen, unabhängig von der eingesetzten Technik "funktioniert". Im einen Falls braucht es halt eine Template Engine, im anderen Fall die Disziplin des Entwicklers, dieses Prinzip einzuhalten.

Du bindest das generierte PHP dann ohne eval() oder include() ein? Das wüsste ich gerne, wie du das machst O_o

Natürlich binde ich den Code ein, klar. Aber das ist doch auch kein Problem. Auch an eval() gibt es nichts auszusetzen. eval() ist eine nützliche Funktion, bei deren Verwendung alle Alarmglocken angehen sollten und man eben ganz genau hingucken muss, dass man nichts falsch macht. Aber deswegen ist da doch nichts verwerfliches dran. Ist doch sehr einschränkend, zu sagen: "Ich benutze kein Smarty, die angewandte Methode birgt in meinen Augen zu viele Gefahren, die die TE unsicher machen könnten."

Basti