nicht angemeldet
PHP als Templatesystem
hi,
hab 2 Dateien, die 1.:
<?php
$mesg = 'Hello Tom';
include "template.php";
?>
und die 2. ('template.php'):
Template: <?php echo $mesg ?>
Ausgegeben wird: Template: Hello Tom
Soweit klar: Vor dem include muss die Variable $mesg einen gültigen Wert haben, dann wird expandiert.
Das gefällt mir aber nicht ;)
Es soll so sein:
include 'template_class.php';
$tt = new TemplateClass;
$tt->expand('Hello Tom'); // Ergebnis soll so sein wie obenstehend
Es ist mir klar, dass das mit include alleine nicht funktioniert, denn danach ist der Käse gegessen. Gibt es noch andere Möglichkeiten?
Bitte mal um Hinweise,
Ho Ch'ti
-
-
Tach!
Gibt es noch andere Möglichkeiten?
Zend Framework Views.
Du meinst
das: Once your controller has assigned variables and called render(), Zend_View then includes the requested view script and executes it "inside" the scope of the Zend_View instance. :sad??
Auf deutsch: Erst die Variablen und dann ein include?
Hotti
-
Tach!
Once your controller has assigned variables and called render(), Zend_View then includes the requested view script and executes it "inside" the scope of the Zend_View instance. :sad??
Auf deutsch: Erst die Variablen und dann ein include?Und das innerhalb einer Funktion/Methode, so dass nur die für das Template wichtigen Variablen gesetzt sind. Das ist kein generelles Sicherheitsfeature, hilft aber das Überschreiben unbeteiligter Variablen zu verhindern, wenn nicht explizit $GLOBALS verwendet wird.
dedlfix.
-
hi,
Once your controller has assigned variables and called render(), Zend_View then includes the requested view script and executes it "inside" the scope of the Zend_View instance. :sad??
Auf deutsch: Erst die Variablen und dann ein include?Und das innerhalb einer Funktion/Methode, so dass nur die für das Template wichtigen Variablen gesetzt sind. Das ist kein generelles Sicherheitsfeature, hilft aber das Überschreiben unbeteiligter Variablen zu verhindern, wenn nicht explizit $GLOBALS verwendet wird.
Das ist ein guter Hinweis, danke Dir!!!
Viele Grüße,
Ho Ch'ti Bout
-
-
-
-
-
Hello Hotti,
<?php
$mesg = 'Hello Tom';
include "template.php";
?>> Das gefällt mir aber nicht ;) Das würde mir auch nicht gefallen! Bei Verwenung "aktiver Templates" findet keine strikte Trennung von Formatbeschreibung (HTML) und Programmfluss statt. Welches Template darf denn bei Dir der Backendsystem-User[1] selber anfertigen? Wie stellst Du sicher, dass er nicht Programmcode einschmuggelt? Es geht nur mit PLATZHALTERN anstelle von VARIABLEN.[2] Diese kannst Du dann durch dein schlaues System austauschen lassen gegen die eignetlichen errechneten Daten. Und da gibt es bisher nur die "Once-" und die "Multi-"typen, wie ich sie in meinem System getauft habe. Bisher komme ich damit aus. Neulich stand ich schon mal an der Wand, weil ich Trennung zwischen Markup und Design nicht finden konnte (Verwendung von nl2br() in der Datenaufbereitung ist verboten!, das ist Sache von CSS) Aber zum Glück funktioniert das ja auch, uns so kännen die Templates absolut funktionsfrei bleiben. [1] authorisierter Nutzer des Backend-Systems, aber kein Trustie des Admins/Programmierers Liebe Grüße aus dem schönen Oberharz Tom vom Berg  -- ☻\_ /▌ / \ Nur selber lernen macht schlau <http://bergpost.annerschbarrich.de>-
Tach!
Bei Verwenung "aktiver Templates" findet keine strikte Trennung von Formatbeschreibung (HTML) und Programmfluss statt.
Stimmt. Ist das aber eine Forderung des Projekts?
Welches Template darf denn bei Dir der Backendsystem-User[1] selber anfertigen?
Alle. Template-Ersteller sind bei mir vertrauenswürdig. Wenn sie es nicht sind, bekommen sie ein CMS und maximal Zugriff auf die CSS-Ressourcen.
Wie stellst Du sicher, dass er nicht Programmcode einschmuggelt?
Kommt drauf an, ob das eine Anforderung oder nicht interessant ist. Letztlich ist es auch sein eigenes Problem, wenn er Dinge einbaut, die nicht funktionieren. Selbst sicherheitsrelevante Aspekte kann man nicht einfach vollständig vor den Mitarbeitern fernhalten.
Es geht nur mit PLATZHALTERN anstelle von VARIABLEN.[2]
(Fußnote fehlt.) Ansonsten: ja, wenn man kein Vertrauensverhältnis aufbauen kann. Wie kommt dann aber das Template ins System und welche Risiken bestehen dabei?
Aber zum Glück funktioniert das ja auch, uns so kännen die Templates absolut funktionsfrei bleiben.
Wenn man es braucht.
dedlfix.
-
Hello,
Bei Verwenung "aktiver Templates" findet keine strikte Trennung von Formatbeschreibung (HTML) und Programmfluss statt.
Stimmt. Ist das aber eine Forderung des Projekts?
Wenn es keine Anfroderung des Projektes wäre, würde sich Hotti doch nicht damit beschäftigen, noch ein weiteres nutzloses Templatesystem zu entwickeln, oder? *gg*
Welches Template darf denn bei Dir der Backendsystem-User[1] selber anfertigen?
Alle. Template-Ersteller sind bei mir vertrauenswürdig. Wenn sie es nicht sind, bekommen sie ein CMS und maximal Zugriff auf die CSS-Ressourcen.
Genau: CMS. Und auch in einem CMS sollte man die Möglichkeit haben, eigene Templates zu gestalteten, ohne damit Zugriff auf den Progammablauf zu bekommen.
Es geht nur mit PLATZHALTERN anstelle von VARIABLEN.[2]
(Fußnote fehlt.) Ansonsten: ja, wenn man kein Vertrauensverhältnis aufbauen kann. Wie kommt dann aber das Template ins System und welche Risiken bestehen dabei?
Keine, die den Server kompromittieren würden. Diejeneigen, die am Client irgendwelchen Blödsinn verursachen, hat man durch diese Art der Trennung noch nicht automatisch verhindert. Da muss man nach Laden des Templates (das übrigens von überall her kommen darf) auch noch aktiv filtern. also z.B. JavaScript ausfiltern oder bestimmte Anweisungen im CSS verhindern (url(), ...).
Wenn man es braucht.
Sonst nimmt man eins von den Hunderten fertiger Systeme...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Tach!
Bei Verwenung "aktiver Templates" findet keine strikte Trennung von Formatbeschreibung (HTML) und Programmfluss statt.
Stimmt. Ist das aber eine Forderung des Projekts?
Wenn es keine Anfroderung des Projektes wäre, würde sich Hotti doch nicht damit beschäftigen, noch ein weiteres nutzloses Templatesystem zu entwickeln, oder? *gg*Laut Thread-Subjekt will er PHP selbst als Template-System verwenden. Der Rest ist die Befriedigung seines NIH-Syndroms.
dedlfix.
-
hi,
NIH-Syndroms.
Was ja wohl bei der NASA mal zu eine fast-crash geführt haben soll, falls das keine Gerücht ist.
http://de.wikipedia.org/wiki/Not-invented-here-Syndrom
mfg
tami
-
-
-
-
Hello,
Es geht nur mit PLATZHALTERN anstelle von VARIABLEN.[2]
als Platzhalter bezeichne ich hier Zeichenketten im Ausgabetext, die _erst__im__Anschluss_ an jegliche Programmbeeinflussungsmöglichkeit gegen ihre textlichen Äquivalente ausgetauscht werden.
Als Variablen bezeichne ich Bezeichner der jeweiligen Programmiersprache des bearbeitenden Systems, die (eventuell) noch in den Prgrammableuf einfließen können und somit interpretiert werden, also Einfluss auf den Programmablauf nehmen könnten.
Vielleicht gibt es bessere Bezeichnugnen dafür; soweit jedenfallse erstmal _meine_ Syntax dafür.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
hi Tom,
Aber zum Glück funktioniert das ja auch, uns so kännen die Templates absolut funktionsfrei bleiben.
Ja, genau, das _müssen_ sie auch! Ein Template hat nicht nut tot, sondern mausetot zu sein! Selbst wenn die Platzhalter $die heißen, darf es keinen, aber auch gar keinen geben, der aus $die ein die() macht oder 'Hello Tom' da reinschreibt, das darf _nur die Templateengine selbst: Da sind wir uns einig, sehr schön ;)
Viele Grüße aus Openheim,
Ho Ch'ti-
Hello Hotti,
Aber zum Glück funktioniert das ja auch, uns so kännen die Templates absolut funktionsfrei bleiben.
Ja, genau, das _müssen_ sie auch! Ein Template hat nicht nur tot, sondern mausetot zu sein! Selbst wenn die Platzhalter $die heißen, darf es keinen, aber auch gar keinen geben, der aus $die ein die() macht oder 'Hello Tom' da reinschreibt, das darf _nur die Templateengine selbst: Da sind wir uns einig, sehr schön ;)
Mir wäre das schon ganz lieb, wenn die Templates zur passenden Zeit anstelle der (Einzahlungs-)Kontonummer des Shopteilnehmers aus der Datenbank da meine einsetzen würden :-)
Wie weit bist Du denn inzwischen mit PHP gekommen? Bis Du immer noch in Abwehrhaltung und kannst Du der Sprache inzwischen (neben ihren ganzen Fehlern) auch positive Dinge abgewinnen?
Wir sollten doch mal ein "Besserwisser-Wochenende" veranstalten :-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
hi Tom,
Wie weit bist Du denn inzwischen mit PHP gekommen? Bis Du immer noch in Abwehrhaltung und kannst Du der Sprache inzwischen (neben ihren ganzen Fehlern) auch positive Dinge abgewinnen?
Sehr weit, es gibt viel Posivies und natürlich gibt es auch Dinge, die gegenüber Perl in PHP nicht so fachgerecht gelöst sind. Auf jeden Fall habe ich schon Einige größere Sachen komplett in PHP geschrieben.
Privat habe ich da noch mein Projekt PHP/Perl-Framework, da steht es dem Anwender (mir) frei, eine Response/Anwendung in Perl ODER in PHP zu programmieren, da ist Beides möglich und die Entscheidung ob PHP oder Perl kann sehr zweckmäßig getroffen werden.
Wir sollten doch mal ein "Besserwisser-Wochenende" veranstalten :-)
Für dieses Wochenende fahre ich erstmal in die andere Richtung nach Baden-Württemberg. Danach werde ich Urlaub machen, vielleicht klappts mal mit dem Harz, das für uns sehr freuen!
Viele Grüße vom Rhein, der heute irgendwie blau schimmert ;)
Hotti-
Hello,
Privat habe ich da noch mein Projekt PHP/Perl-Framework, da steht es dem Anwender (mir) frei, eine Response/Anwendung in Perl ODER in PHP zu programmieren, da ist Beides möglich und die Entscheidung ob PHP oder Perl kann sehr zweckmäßig getroffen werden.
Das ist aber keine Sache von PHP oder Perl, sondern des Protokolls der verwendeten Client-Server-Anwendung. _HTTP_ ermöglichst es, hier auf beiden Seiten vollkommene Sprachenfreiheit zu erzeugen!
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
Privat habe ich da noch mein Projekt PHP/Perl-Framework, da steht es dem Anwender (mir) frei, eine Response/Anwendung in Perl ODER in PHP zu programmieren, da ist Beides möglich und die Entscheidung ob PHP oder Perl kann sehr zweckmäßig getroffen werden.
Das ist aber keine Sache von PHP oder Perl, sondern des Protokolls der verwendeten Client-Server-Anwendung. _HTTP_ ermöglichst es, hier auf beiden Seiten vollkommene Sprachenfreiheit zu erzeugen!
Richtig, das war schon immer so ;)
Schlimmer noch: Dem Besucher ist es egal, ob die Response in PHP oder in Perl erstellt wird ;)
Hotti
-
-
-
-
hi,
hi Tom,
Aber zum Glück funktioniert das ja auch, uns so kännen die Templates absolut funktionsfrei bleiben.
Ja, genau, das _müssen_ sie auch! Ein Template hat nicht nut tot, sondern mausetot zu sein! Selbst wenn die Platzhalter $die heißen, darf es keinen, aber auch gar keinen geben, der aus $die ein die() macht oder 'Hello Tom' da reinschreibt, das darf _nur die Templateengine selbst: Da sind wir uns einig, sehr schön ;)
Also aus meiner Sicht sollte im Template stehen:
contentPagePart.phtml:
<ul> <?php foreach($rows as $line):?> <li><?php echo $line?></li> <?php endforeach?> </ul>Dann steht im Controller:
$rows = MyDataClass::get("something"); ob_start(); include("contentPagePart.phtml"); //man beachte das .phtml $content = ob_get_clean(); $menu = Menu::create(); include("myHtmlFrame.phtml"); // oder View::show("myHtmlFrame") o.ä;in myHtmlFrame.phtml dann:
<html> <head> <title><?php echo $title?></title> </head> <body> <menu><?echo $menu?></menu> <div id="content"> <?php echo $content?> </div> </body> </html>Denn PHP ist ja eine Templatesprache ;-).
mfg
tami
-
Hello,
Also aus meiner Sicht sollte im Template stehen:
contentPagePart.phtml:
<ul>
<?php foreach($rows as $line):?>
<li><?php echo $line?></li>
<?php endforeach?>
</ul>Das wäre dann aber immer noch die Verwendung einer "Expansionssprache", aber noch lange keine passive "Templateersetzung". Liebe Grüße aus dem schönen Oberharz Tom vom Berg  -- ☻\_ /▌ / \ Nur selber lernen macht schlau <http://bergpost.annerschbarrich.de>-
hi,
Hello,
Also aus meiner Sicht sollte im Template stehen:
contentPagePart.phtml:
<ul>
<?php foreach($rows as $line):?>
<li><?php echo $line?></li>
<?php endforeach?>
</ul>> > Das wäre dann aber immer noch die Verwendung einer "Expansionssprache", aber noch lange keine passive "Templateersetzung". Templatesprache? <http://de.wikipedia.org/wiki/Template_Engine#PHP_Template_Engines> "Der Vorteil liegt in der einfachen Verwendung. Es muss keine zusätzliche Bibliothek installiert werden, auch ist diese Vorgehensweise für PHP-erfahrene Entwickler am leichtesten zu verstehen und folgt dem Prinzip der geringsten Überraschung. Die Verwendung einer gesonderten Template Engine für PHP ist daher nicht erforderlich. Dennoch existieren besonders für PHP eine sehr große Zahl von Engines" mfg tami
-
-
hi,
Denn PHP ist ja eine Templatesprache ;-).
Gehen wir mal so ran: Mein Framework ermöglicht die freie Wahl der serverseitigen Sprache, PHP oder Perl.
Die Templates dazu müssen erstens davon unabhängig sein und zweitens alle gleich aussehen.
Wenn PHP die Templatespache wäre, gänge das von vornherein nicht für Prozesse, die über Perl geführt werden. Es ist jedoch trotzdem eine schöne Diskussion hier geworden, danke an Alle.
Hotti
-
-
-
-
hi,
hi,
hab 2 Dateien, die 1.:
<?php
$mesg = 'Hello Tom';
include "template.php";
?>> > und die 2. ('template.php'): > `Template: <?php echo $mesg ?>`{:.language-php} > > Ausgegeben wird: Template: Hello Tom > Soweit klar: Vor dem include muss die Variable $mesg einen gültigen Wert haben, dann wird expandiert. > > Das gefällt mir aber nicht ;) > Es soll so sein: > ~~~php > include 'template_class.php'; > $tt = new TemplateClass; > $tt->expand('Hello Tom'); // Ergebnis soll so sein wie obenstehend >ob_start() und ob_get_clean();
mfg
tami
-
hi,
ob_start() und ob_get_clean();
Jow, habe ich mir heute angeschaut, Out(put) buffering, hat jedoch seine Tücken.
Indes: Es darf nur _einen geben, der Code im Template zum Leben erweckz und das ist die Template-Engine, sonst niemand.
Ho Ch'ti
-
hi,
hi,
ob_start() und ob_get_clean();
Jow, habe ich mir heute angeschaut, Out(put) buffering, hat jedoch seine Tücken.
Indes: Es darf nur _einen geben, der Code im Template zum Leben erweckz und das ist die Template-Engine, sonst niemand.
Naja, wenn Du das so willst. Andere (s.a. Zend Framework) sehen das anders. Denn PHP ist ja nun mal eine Templatesprache.
mfg
tami
-
Hello,
Indes: Es darf nur _einen geben, der Code im Template zum Leben erweckz und das ist die Template-Engine, sonst niemand.
Naja, wenn Du das so willst. Andere (s.a. Zend Framework) sehen das anders. Denn PHP ist ja nun mal eine Templatesprache.
Da sehen sie eben nur den Teller, aber noch nicht einmal den Rand - und schon gar nicht darüberhinaus.
Aber den Designmangel kann man ja mit wilden OOP-Konstrukten und -Patterns wieder wett machen, oder?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Tach!
Naja, wenn Du das so willst. Andere (s.a. Zend Framework) sehen das anders. Denn PHP ist ja nun mal eine Templatesprache.
Da sehen sie eben nur den Teller, aber noch nicht einmal den Rand - und schon gar nicht darüberhinaus.Sie sehen das für den Default-Renderer so, weil das für eine ganze Menge Projekte völlig ausreichend ist. Wenn du ein großes System mit extern erstellten Templates baust, kannst du einen anderen Renderer verwenden, der mit Smarty oder ähnlichem zusammenarbeitet. Durch die Austauschbarkeit des Renderers haben sie weit über den Tellerrand hinaus Möglichkeiten geschaffen.
dedlfix.
-
Hello,
Da sehen sie eben nur den Teller, aber noch nicht einmal den Rand - und schon gar nicht darüberhinaus.
Sie sehen das für den Default-Renderer so, weil das für eine ganze Menge Projekte völlig ausreichend ist. Wenn du ein großes System mit extern erstellten Templates baust, kannst du einen anderen Renderer verwenden, der mit Smarty oder ähnlichem zusammenarbeitet. Durch die Austauschbarkeit des Renderers haben sie weit über den Tellerrand hinaus Möglichkeiten geschaffen.
Gut, ich kauf mir mal ein neues Tischset, damit die Extra-Möglichkeiten darauf auch noch Platz finden :-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
hi,
Da sehen sie eben nur den Teller, aber noch nicht einmal den Rand - und schon gar nicht darüberhinaus.
Sie sehen das für den Default-Renderer so, weil das für eine ganze Menge Projekte völlig ausreichend ist. Wenn du ein großes System mit extern erstellten Templates baust, kannst du einen anderen Renderer verwenden, der mit Smarty oder ähnlichem zusammenarbeitet. Durch die Austauschbarkeit des Renderers haben sie weit über den Tellerrand hinaus Möglichkeiten geschaffen.
Gut, ich kauf mir mal ein neues Tischset, damit die Extra-Möglichkeiten darauf auch noch Platz finden :-)
In OOP: Du musst nicht einmal die Funktionen austauschen, es reicht, die Klasse auszutauschen :D
Btw., in meinem Framework steht die Wahl "Templatesystem" dem Anwender völlig frei. In der Grundausstattung gibt es ein sehr einfaches eigenenes TS was für viele Sachen völlig ausreichend ist.
Nur eine Sache darfst Du beim Inherit/OOP nicht aus dem Auge verlieren: Die Basisklassen vergreisen und die Verjüngung findet nur in den abgeleiteten Klassen statt... aber: Isses im wirklichen Leben nicht ganz genauso!!!????
Ja, fast, nur, hier ist der Unterschied:
Im wirklichen Leben sterben die Alten von selbst und Sterbehilfe ist verboten.Schönes Wochenende,
Grüße an Alle,
Ho Ch'ti Bout
-
-
-
hi;
Aber den Designmangel kann man ja mit wilden OOP-Konstrukten und -Patterns wieder wett machen, oder?
Was OOP betrifft, kann ich PHP mit Perl gut vergleichen: Sowohl mit PHP- als auch mit Perl-OOP lassen sich viele praktische Programmieraufgaben fachgerecht lösen, das ist Fakt!
Ansonsten hätte ich kein PHP/Perl-Framework gebaut, wo _beide_ Programmiersprachen _gleichberechtigt_ nebeneinander in friedlicher Koexistenz leben ;)
Freilich musste ich mir hinsichtlich Konsolidierung was einfallen lassen, z.B., dass die in der gemeinsamen Konfiguration zu vergebenen Klassennamen auch den gleichen Namen-Konventionen genügen, z.B. kann class=Manager::PDF sowohl eine PHP- als auch eine Perl-Klasse sein:
Perl findet die zugehörige Datei anhand des Klassennamen, in PHP ist das eine Frage der Vereinbarung und auf jeden Fall machbar, das ist das Entscheidende.
Tja, wer hätte das gedacht: Bisher habe ich auf meinen privaten Demo-Seiten nur eine DB-Anwendung und die ist in PHP programmiert ;)
Und im (bis heute) Job: Kein Copy&Paste vorhandener PHP-Klassen, da wird einfach eine Subklasse aus dem Core abgeleitet und fertig! D.h., eine mach_mal_das()-Methode überschreibe ich ganze einfach, wenn die dasselbe machen soll wie bisher, nur eben auf modernere Art und Weise: Z.B. unter Verwendung eines Templatesystems.
Hotti
-
-
-
-