nicht angemeldet dedlfix
Der Martin
Rolf b
Tabellenkalk
dedlfix
dedlfix
Tabellenkalk
Rolf b
Tabellenkalk
mermshaus
Felix Riesterer
MB
moin community,
eine allgemeine Frage. Was sind das {{ ... }} für platzhalter, doppelt geschweifte klammern??? Ich habe sie bei ziehmlich vielen sprachen gesehen unteranderem in php und javascript. Ist das ein selbst definierter platzhalter oder vordefiniert???
vlg MB
wo denn in PHP?
wo denn in PHP?
na als platzhalter auf htmlseiten z.B. {{title}} oder {{content}} in html und dann, nehme ich an, mit php integriert, oder abngularjs da gibts das auch, aber mehr weis ich wirklich nicht. Ich wollte einfach wissen, ob das n selbstdefinierter platzhalter is und wenn ja für was?
vlg MB
Hallo
wo denn in PHP?
na als platzhalter auf htmlseiten z.B. {{title}} oder {{content}} in html
Das ist, was es ist.
und dann, nehme ich an, mit php integriert
Nein.
Ich wollte einfach wissen, ob das n selbstdefinierter platzhalter is und wenn ja für was?
Ja, es ist ein Platzhalter, der gegen realen Inhalt ausgetauscht werden wird. Das geschieht natürlich mit Programmiersprachen, deeshalb gehört die Platzhaltersyntax aber nicht zu den Sprachen selbst. Es gäbe auch noch andere Versionen {Platzhalter} oder <%Platzhalter%> oder noch ganz andere Systeme, die ein Programmierer oder ein Team für sich ausgewählt haben könnte.
Tschö, Auge
Tach!
na als platzhalter auf htmlseiten z.B. {{title}} oder {{content}} in html und dann, nehme ich an, mit php integriert, oder abngularjs da gibts das auch, aber mehr weis ich wirklich nicht.
PHP hat sowas nicht integriert. Deine Annahme ist deshalb nicht richtig. Mit PHP kann man aber Programme schreiben, die eine beliebige Zeichenfolge lesen und auf irgendeine individuelle Art und Weise interpretieren. Ohne dass PHP selbst eine solche Syntax kennen müsste.
HTML hat solch ein Syntaxelement ebenfalls nicht. Angular verwendet es jedoch. Auch dann steht es qausi nicht in HTML, sondern Angular filtert das raus, bevor es der Browser zu Gesicht bekommt. (Jedenfalls theoretisch. Praktisch sieht es der Browser in manchen Situationen doch, bevor Angular zu arbeiten anfangen kann, aber dann hat das keine Auswirkungen, weil es ganz normale Zeichen für ihn sind.)
Angular nimmt es, um zu kennzeichnen, dass da der Inhalt ein zu berechnender Ausdruck ist. Manche Template-Systeme kennzeichnen damit vielleicht einen Platzhalter, vielleicht aber auch was anders.
Ich wollte einfach wissen, ob das n selbstdefinierter platzhalter is und wenn ja für was?
Darauf gibt es keine allgemeine Antwort. Für die einen ist es Duplo, für die anderen die längste Praline der Welt.
Du könntest auch fragen, wofür = steht. Nun, auch darauf kann man keine allgemeingültige Antwort geben. Einige Sprachen verwenden das als Zuweisung, andere als Vergleichsoperator, wieder andere um eine Überschrift zu kennzeichnen, manchmal ist es aber auch einfach nur ein Zeichen. Je nach Kontext hat das also eine andere Bedeutung. Als Programmierer musst du in der Lage sein, diese Kontexte auseinanderzuhalten, dann kannst du sowohl verstehen, was bestimmer Code macht, als auch Code so formulieren, dass die beteiligten Systeme das machen, was du möchtest.
dedlfix.
Mit PHP kann man aber Programme schreiben, die eine beliebige Zeichenfolge lesen und auf irgendeine individuelle Art und Weise interpretieren. Ohne dass PHP selbst eine solche Syntax kennen müsste.
das habe ich vermutet aber eben nur vermutet.
Ich wollte einfach wissen, ob das n selbstdefinierter platzhalter is und wenn ja für was?
Darauf gibt es keine allgemeine Antwort. Für die einen ist es Duplo, für die anderen die längste Praline der Welt.
sehr schöne analogy :D.
Als Programmierer musst du in der Lage sein, diese Kontexte auseinanderzuhalten, dann kannst du sowohl verstehen, was bestimmer Code macht, als auch Code so formulieren, dass die beteiligten Systeme das machen, was du möchtest.
ok, ich hab jetzt von meinen vermutungen gewissheit. Kannst du mir n anwendungsbeispiel geben wie ich martin auch bat? muss nicht groß sein es sei den dieses braucht diese dimensonen.
vlg MB
Tach!
ok, ich hab jetzt von meinen vermutungen gewissheit. Kannst du mir n anwendungsbeispiel geben wie ich martin auch bat? muss nicht groß sein es sei den dieses braucht diese dimensonen.
Anwendungsbeispiele findest du in den Dokumentationen der jeweiligen Systeme. Da es keine universelle systemübergreifende Verwendung sondern stets eine individuelle ist, kann man da prinzipbedingt kein allgemeines Beispiel geben. Um die Frage wenigstens teilweise beantworten zu können, müsste ich mich auf ein konkretes System beziehen, und dann hast du immer noch keine Antwort für den Rest oder dein eigentliches Problem, das dich vielleicht veranlasst hat, die Frage zu formulieren. Angular wurde ja schon genannt. In jedem Einsteiger-Tutorial wirst du Beispiele für die dortige Verwendung der {{}}-Syntax finden. Um nur mal ein System herauszugreifen.
Übrigens passiert es auch Leuten, die sich einbilden eine gehörige Portion Erfahrung zu haben, dass sie unbekannte Syntax vorfinden - oder Syntaxzusammenstellungen, deren Sinn sie (noch) nicht kennen. Zum Beispiel lief mir irgendwann in Javascript das Konstrukt !!variable über den Weg. Ist !! ein Syntaxelement irgeneiner neueren Javascript-Version, das ich noch nicht kenne? Nein, stellte sich nach Recherche heraus, das ist ein ganz normaler Negator ! zweimal hintereinandergeschrieben. Sieht ziemlich sinnlos aus, wenn man einen Wert negiert und ihn gleich wieder negiert. Sieht aber nur so aus, denn was eigentlich passiert ist eine implizierte Typkonvertierung nach Boolean. Das Konstrukt !! erzeugt also aus einem Wert, der truthy oder falsy aussieht, ein echtes boolesches true oder false.
dedlfix.
Moin,
Kannst du mir n anwendungsbeispiel geben?
Um in meinem Veranstaltungskalender eine individuelle Webseite zu erzeugen mit den angeforderten Daten, trenne ich Programm und HTML in zwei Dateien.
Das PHP-Programm holt die angeforderten Daten aus der MySQL Datenbank und stellt sie in ein PHP-Array. Dieses Array wird an ein PHP-Unterprogramm weitergereicht, das die HTML-Datei mit den Platzhaltern liest, diese ersetzt und das Ergebnis an den Browser ausliefert.
Hier das Ergebnis: remso.eu/?TYP=21 (Zirkus)
Hier der (gekürzte) PHP-Programmteil, der eine Position für die Liste zusammenstellt:
Auge
Gunnar Bittersmann$display = array();
...
$display[] = array(
'segment' => 'position'
,'[ort_plz]' => $row['ort_plz'].''
,'[ort_name]' => $row['ort_name']
,'[tt]' => substr($row['tag'],8,2).''
,'[mm]' => substr($row['tag'],5,2).''
);
Und hier die Original-Platzhalterdatei, in die die Daten des Arrays gefüllt werden: remso.eu/500/p591_de.htm, Die solltest du dir als Quelltext anzeigen lassen.
Du siehst "Segmente" wie
<!-- [position] -->
... [tt].[mm]. ...
<!-- [/position] -->
Die Platzhalter werden durch die Daten des Arrays ersetzt und so oft ausgegeben, wie es die Liste erfordert, hier als 25 mal.
Ich kann statt "[tt]" genausogut "{{starttag}}", "StArTtAg" oder "<%datum%>" nehmen, es muss nur zweimal dieselbe Zeichenfolge sein. Und zwar eine Zeichenfolge, die sonst in diesem Segment der Platzhalter-Datei nicht vorkommt. Ich empfand [tt] im Textfluss als gut lesbar.
Tach!
eine allgemeine Frage. Was sind das {{ ... }} für platzhalter, doppelt geschweifte klammern??? Ich habe sie bei ziehmlich vielen sprachen gesehen unteranderem in php und javascript.
Das sind weder Syntaxelemente von PHP noch von Javascript, noch kenne ich sie von anderen Programmiersprachen. Du müsstest deren Bedeutung in den Anleitungen der jeweiligen Anwendungen oder Bibliotheken nachschlagen.
dedlfix.
hi dedlfix
eine allgemeine Frage. Was sind das {{ ... }} für platzhalter, doppelt geschweifte klammern??? Ich habe sie bei ziehmlich vielen sprachen gesehen unteranderem in php und javascript.
Das sind weder Syntaxelemente von PHP noch von Javascript, noch kenne ich sie von anderen Programmiersprachen. Du müsstest deren Bedeutung in den Anleitungen der jeweiligen Anwendungen oder Bibliotheken nachschlagen.
ok dankle für den hinweis! Bis jetzt habe ich nichts dergleichen gefunden :/. deswegen meine Frage hier im Forum.
vlg MB
Hallo,
eine allgemeine Frage. Was sind das {{ ... }} für platzhalter, doppelt geschweifte klammern??? Ich habe sie bei ziehmlich vielen sprachen gesehen unteranderem in php und javascript. Ist das ein selbst definierter platzhalter oder vordefiniert???
wie schon erwähnt wurde, ist das nichts, was in der Programmiersprache selbst eine spezielle Bedeutung hat. Vermutlich hast du das nicht im Programmcode an sich gesehen, sondern in Textfragmenten, über die eine Template Engine herfallen soll, um Platzhalter zu ersetzen.
So long,
Martin
moin martin,
eine allgemeine Frage. Was sind das {{ ... }} für platzhalter, doppelt geschweifte klammern??? Ich habe sie bei ziehmlich vielen sprachen gesehen unteranderem in php und javascript. Ist das ein selbst definierter platzhalter oder vordefiniert???
wie schon erwähnt wurde, ist das nichts, was in der Programmiersprache selbst eine spezielle Bedeutung hat. Vermutlich hast du das nicht im Programmcode an sich gesehen, sondern in Textfragmenten, über die eine Template Engine herfallen soll, um Platzhalter zu ersetzen.
ja so wollte ich das ausdrücken. Welchen speziellen speziellen nutzen hat das??? Warum geht man nicht einfach hin und macht sowas:
<h1><?php echo $title; ?></h1>
warum so
<h1>{{title}}</h1>
Hallo,
wie schon erwähnt wurde, ist das nichts, was in der Programmiersprache selbst eine spezielle Bedeutung hat. Vermutlich hast du das nicht im Programmcode an sich gesehen, sondern in Textfragmenten, über die eine Template Engine herfallen soll, um Platzhalter zu ersetzen.
ja so wollte ich das ausdrücken. Welchen speziellen speziellen nutzen hat das???
hauptsächlich den, dass man nicht Programmcode und Nutzinhalt mischen muss.
Warum geht man nicht einfach hin und macht sowas:
<h1><?php echo $title; ?></h1>warum so
<h1>{{title}}</h1>
Im zweiten Fall muss derjenige, der das Template erstellt, kein Programmierer sein, er muss die verwendete Scriptsprache (hier im Beispiel PHP) nicht kennen, und er kann auch nichts wirklich grob kaputtmachen.
Auch das spätere Ändern der Inhalte ist einfacher; man braucht bloß {{title}} innerhalb des Textes an eine andere Stelle zu setzen und muss nicht wieder in die Programmlogik eingreifen.
So long,
Martin
<h1>{{title}}</h1>Im zweiten Fall muss derjenige, der das Template erstellt, kein Programmierer sein, er muss die verwendete Scriptsprache (hier im Beispiel PHP) nicht kennen, und er kann auch nichts wirklich grob kaputtmachen.
klingt einleuchtend.
Auch das spätere Ändern der Inhalte ist einfacher; man braucht bloß {{title}} innerhalb des Textes an eine andere Stelle zu setzen und muss nicht wieder in die Programmlogik eingreifen.
gibst du mir n kleines Anwenungsbeispiel?
vlg MB
(Edit: Parallel zu Dedlfix und Martin gepostet :) )
Google hat mir verraten, was es in Java bedeutet:
x = new HashMap(){{put("id", "1234");}}
Die äußeren Klammern erzeugen eine anonyme Subklasse von HashMap, die inneren zeigen einen anonymen Instanz-Initializer an. Das gilt in Java als Antipattern. Grund ist, dass hier pro Aufruf eine neuer Typ erzeugt wird, und das frisst natürlich Speicher. Abgesehen von dem merkwürdigen Aussehen dieses Konstrukts...
Allerdings wäre mir nicht bekannt, dass {{...}} in JavaScript oder PHP eine solche Semantik hätte. Es gibt aber Template-Engines bzw. Frameworks, die double braces oder triple braces nutzen, z.B. Angular oder Laravel. Das ist dann aber on top von PHP oder JS, nicht Teil davon.
Rolf
Hallo,
Die äußeren Klammern, die inneren
D.h. sie haben nicht als doppelte Klammern eine Bedeutung, sondern jedes Klammerpaar für sich und das auch noch unterschiedlich!? wtf, Java?
Gruß
Kalk
Tach!
Die äußeren Klammern, die inneren
D.h. sie haben nicht als doppelte Klammern eine Bedeutung, sondern jedes Klammerpaar für sich und das auch noch unterschiedlich!? wtf, Java?
Nun, auch in anderen Sprachen kann man beliebigen Code in {} einrahmen und den auch wieder {}-klammern. In C# beispielsweise erzeugt das {}-Paar einen eigenen Scope, in PHP nicht. Andererseits gibt es in C# auch Konstrukte, da haben die {}-Klammern nicht die Bedeutung eines Blocks, sondern arbeiten als Objekt-Initialisierer oder auch als Element der Template-String-Syntax. Kontextabhängig unterschiedliche Bedeutungen für dieselben Zeichen.
dedlfix.
hi rolf,
Allerdings wäre mir nicht bekannt, dass {{...}} in JavaScript oder PHP eine solche Semantik hätte.
das meine ich nicht. sry wenns so intepretiert wurde.
Es gibt aber Template-Engines bzw. Frameworks, die double braces oder triple braces nutzen, z.B. Angular oder Laravel.
genau. Wie funktioniert die Template-Engine? warum nicht eine definierte syntax von der jeweiligen programmiersprache?
vlg MB
eine allgemeine Frage. Was sind das {{ ... }} für platzhalter,
Du meinst sicher sowas:
Template:
Kleine {{FARBE}} Männchen stammen vom {{PLANET}}.
Platzhalter sind immer irgendwie "selbst definiert". Es sind einfach Zeichenfolgen von denen der Verwender hofft, dass diese in den Templates
Deshalb wohl die von Dir irgendwo gesehene Verwendung von {{ und }} als Begrenzer von Platzhaltern.
Im Übrigen ist speziell in PHP diese Vorgehensweise nicht wirklich eine gute Idee. PHP ist selbst Templatesprache genug.
Obiges Beispiel müsste man ETWA so bearbeiten:
<!-- template: file template.txt //-->
Kleine {{FARBE}} Männchen stammen vom {{PLANET}}.
<?php
/**
* Desciption: Das ist Mist!
**/
## Daten:
$tpl['FARBE'] = 'grüne';
$tpl['PLANET'] = 'Mars';
## "Minimale Template-Engine"
$template = file_get_contents('template.txt');
foreach ( array_keys($tpl) as $str ) {
$search[] = '{{' . $str . '}}';
$replace[]= $tpl[$str];
}
echo str_replace( $search, $replace, $template );
Das Ergebnis:
<!-- template: file template.txt //-->
Kleine grüne Männchen stammen vom Mars.
Sieht zwar gut aus, ist aber, weil PHP bereits eine Templatesprache ist, UNSINN.
weil mit:
<!-- template: file template.php //-->
Kleine <?=$tpl['FARBE'];?> Männchen stammen vom <?=$tpl['PLANET'];?>.
und
<?php
## Daten:
$tpl['FARBE'] = 'grüne';
$tpl['PLANET'] = 'Mars';
##
require( 'template.php' );
Ergebnis:
<!-- template: file template.php //-->
Kleine grüne Männchen stammen vom Mars.
das ganze viel eleganter zu bewerkstelligen ist. Es ist schneller, es gibt praktikable Fehlermeldungen (Notizen), Editoren zeigen das nativ in PHP geschriebene Template "schön bunt" an - und kürzer ist es auch noch....
Tach!
das ganze viel eleganter zu bewerkstelligen ist. Es ist schneller, es gibt praktikable Fehlermeldungen (Notizen), Editoren zeigen das nativ in PHP geschriebene Template "schön bunt" an - und kürzer ist es auch noch....
Und in beiden Fällen ist der Kontextwechsel unbeachtet geblieben. Gut, im vorliegenden Fall mit den beiden Stringliteralen, die in die Variablen geschrieben werden, ist das überschaubar ungefährlich, aber in der Realität kommen die Daten sonstwoher und können sonstwas enthalten, inklusive Zeichen, die im Ausgabekontext eine besondere Bedeutung haben. Deshalb, liebe Kinder, wenn ihr das (nicht nur) zu Hause nachmacht, achtet immer auf das korrekte Escaping. Ich kann in diesem Fall nicht sagen, dass die Anwendung von htmlspecialchars() richtig wäre, denn aus dem Beispiel geht nicht hervor, dass es sich um HTML handelt. Es könnte auch reiner Text ohne irgendwelche Syntax sein, dann wäre das sogar ohne weiteres richtig. Also kurz: gegebenenfalls Kontextwechsel passend zur Ausgabe beachten!
dedlfix.
<!-- template: file template.php //--> Kleine <?=$tpl['FARBE'];?> Männchen stammen vom <?=$tpl['PLANET'];?>.und
<?php ## Daten: $tpl['FARBE'] = 'grüne'; $tpl['PLANET'] = 'Mars'; ## require( 'template.php' );Ergebnis:
<!-- template: file template.php //--> Kleine grüne Männchen stammen vom Mars.das ganze viel eleganter zu bewerkstelligen ist. Es ist schneller, es gibt praktikable Fehlermeldungen (Notizen), Editoren zeigen das nativ in PHP geschriebene Template "schön bunt" an - und kürzer ist es auch noch...
GEHEIMTIPP:
Wenn man die Ausgaben im Speicher (einer Variablen) braucht, dann bietet sich Outputbuffering an:
ob_start();
require('template.php');
$text = ob_get_contents();
ob_end_clean();
echo '<p>', preg_replace( '#<!--.*//-->\n#', '', $text ), '</p>', "\n";
Ergebnis:
<p>Kleine grüne Männchen stammen vom Mars.</p>
... würde hier nachträglich den HTML-Kommentar entfernen und den Text in den <p>-Tag "einrahmen". Ist ein schlechtes Beispiel - ich will aber bei dem angefangenen bleiben.
Templategefummel ist eine praktische Angelegenheit. Perl's Problem viele Jahre war das Fehlen einer TE (Templating Engine) und so hab ich mir das Teil selbst gebaut wie viele andere Perlkollegen. Nebenher machte ich Erfahrungen mit sehr umfangreichen TE's wie z.B. Perl's Template::Toolkit (TT) und kam immer wieder zu dem Schluss, dass in der Praxis solch Umfang wie das TT bietet, unsinnig ist. In Fakt kochte da jeder Designer sein eigenes Süppchen und exportierte Stück für Stück die Programmlogik ins Template -- Ein Horror für den CTO (Onion Pattern).
Die Praxis besteht darin, umfangreiche Seiten Beispiel über einfache Templates abzuwickeln, d.h., Loops sollte eine TE schon können:
# AJAX Response erzeugen
$self->{CONTENT} = XR::xr(
q(
<h2>%title%</h2>
<dl>
%loop_slice%
<dt><strong> %title% </strong></dt>
<dd> %descr% </dd>
%endloop%
</dl>
),
{
title => $hmap->{$url},
slice => $slice
}
);
// Response ins DOM pflanzen
<div id="pro"></div>
<script>
function pro(url){
throbber(true);
var xhr = new XMLHttpRequest();
xhr.open('GET','%url%?url='+url);
xhr.onload = function(){
throbber(false);
if(this.status != 200) return pretext(this.response);
$('#pro').html(this.response);
}
xhr.send();
}
Wobei es eigentlich völlig Wurst ist, ob die Einzeldaten serverseitig ins Template gerendert oder als JSON gesendet werden, wenn Templates für Perl wie JS identisch aufgebaut sind. Mehr dazu auf meinen FW-Seiten und ja, den CODE für die TE hab ich da auch veröffentlicht -- Jahrelang bewährt ;)
Nebenher machte ich Erfahrungen mit sehr umfangreichen TE's wie z.B. Perl's Template::Toolkit (TT) und kam immer wieder zu dem Schluss, dass in der Praxis solch Umfang wie das TT bietet, unsinnig ist.
HTML::Template sollte Dir da deutlich besser gefallen.
In Fakt kochte da jeder Designer sein eigenes Süppchen und exportierte Stück für Stück die Programmlogik ins Template -- Ein Horror für den CTO (Onion Pattern).
Ja, das möchte man nicht.
Die Praxis besteht darin, umfangreiche Seiten Beispiel über einfache Templates abzuwickeln, d.h., Loops sollte eine TE schon können:
Loops, aber auch Fallunterscheidungen, Escaping-Funktionalität, Includes.
Wobei es eigentlich völlig Wurst ist, ob die Einzeldaten serverseitig ins Template gerendert oder als JSON gesendet werden, wenn Templates für Perl wie JS identisch aufgebaut sind.
Der Template-Engine sollte das egal sein, stimmt. Insgesamt völlig Wurst ist es aber bestimmt nicht.
Nebenher machte ich Erfahrungen mit sehr umfangreichen TE's wie z.B. Perl's Template::Toolkit (TT) und kam immer wieder zu dem Schluss, dass in der Praxis solch Umfang wie das TT bietet, unsinnig ist.
HTML::Template sollte Dir da deutlich besser gefallen.
Meine Eigenentwicklung ist deutlich performanter. Meine Templates sind jedoch kompatibel zu HTML::Template was die %-String-Begrenzer betrifft.
In Fakt kochte da jeder Designer sein eigenes Süppchen und exportierte Stück für Stück die Programmlogik ins Template -- Ein Horror für den CTO (Onion Pattern).
Ja, das möchte man nicht.
Die Praxis besteht darin, umfangreiche Seiten Beispiel über einfache Templates abzuwickeln, d.h., Loops sollte eine TE schon können:
Loops, aber auch Fallunterscheidungen, Escaping-Funktionalität, Includes.
Einfache if/else/endif ja, damit kann man ja auch das Template umschalten. Was Includes ggf. überflüssig macht ;)
Wobei es eigentlich völlig Wurst ist, ob die Einzeldaten serverseitig ins Template gerendert oder als JSON gesendet werden, wenn Templates für Perl wie JS identisch aufgebaut sind.
Der Template-Engine sollte das egal sein, stimmt. Insgesamt völlig Wurst ist es aber bestimmt nicht.
Die Oberbegriffe für das was ich damit meine sind Portabilität, Transparenz und Abstraktion.
HTML::Template sollte Dir da deutlich besser gefallen.
Meine Eigenentwicklung ist deutlich performanter.
HTML::Template sollte Dir da deutlich besser gefallen.
Meine Eigenentwicklung ist deutlich performanter.
Natürlich.
Hallo,
Sieht zwar gut aus, ist aber, weil PHP bereits eine Templatesprache ist, UNSINN.
Wenn die Person, die die Seite mit PHP programmiert, dieselbe ist, die dann die Inhalte einstellt, dann hast du recht. Wenn jedoch jemand Inhalte auf Webseiten einstellen soll, der keine Ahnung von PHP hat, dann kann die Lösung mit den geschweiften Klammerpaaren den Lernaufwand effizient senken.
Gruß
Kalk
dann kann die Lösung mit den geschweiften Klammerpaaren den Lernaufwand effizient senken.
Dann kann das folgende ganz einfach und effizient den Aufwand für den Programmierer und das Programm senken:
<!-- template: file template.txt //-->
Kleine {{FARBE}} Männchen stammen vom {{PLANET}}.
Dann hilft sowas:
#! /usr/bin/bash
### file myTemplateToPHP.sh
## replace simple Placeholders with php-Syntax
## {{ with <?=$tpl['
## }} with '];?>
placeHolderLeft='{{';
placeHolderRight='}}';
replacementLeft="<?=\$tpl['";
replacementrRight="'];?>";
while [ $1 ]; do
fileIn=$1;
if [ -w $fileIn ]; then
#txt=`cat ${fileIn} | tr "\n" '\n'`;
txt='';
while read row ; do
row=$(echo ${row} | sed "s#${placeHolderLeft}#${replacementLeft}#g");
row=$(echo ${row} | sed -s "s#${placeHolderRight}#${replacementrRight}#g";);
txt="${txt}\n${row}";
done < ${fileIn};
fileOut=$(echo ${fileIn} | sed -s 's#\.txt$#.php#i');
echo ${txt} > ${fileOut};
err=$?;
if [ "0"=="${err}" ]; then
echo "Datei '${fileOut}' aus '${fileIn}' erzeugt.";
else
echo "Beim Schreiben der Datei '${fileOut}' (aus '${fileIn}') trat ein Fehler auf.";
fi
else
echo "Die Datei '${fileIn}' gibt es nicht.";
fi
shift;
done;
RUN:
myTemplateToPHP.sh *.txt
Ergebnis:
Datei 'template.php' aus 'template.txt' erzeugt.
cat template.php
<!-- template: file template.txt //-->
Kleine <?=$tpl['FARBE'];?> Männchen stammen vom <?=$tpl['PLANET'];?>
Ja guuuut - kann man machen, muss man aber nicht (wobei das Minus nicht von mir ist...)
In solchen Fällen würde ich Smarty vorschlagen wollen, der compiliert Templates automatisch in PHP.
Rolf
(wobei das Minus nicht von mir ist...)
Nicht jeder ist so ein ... [Man darf hier die angebrachten Worte nicht verwenden. Wer weiß wer sich dann ... fühlt.]
@@Google weiß alles
Nicht jeder ist so ein ...
Beleidigte Leberwurst?
[Man darf hier die angebrachten Worte nicht verwenden.
Nicht?
Wer weiß wer sich dann ... fühlt.]
Eingeschnappt?
LLAP 🖖
Ich mach hier zu. Das führt ja wieder zu nichts.
In solchen Fällen würde ich Smarty vorschlagen wollen, der compiliert Templates automatisch in PHP.
Ja, Smarty ist für manches eine Lösung, insbesondere im Hinblick auf den Cache. Dann ist aber der von manchem gewünschte Effekt, dass es für die Template-Ersteller im Hinblick auf den Lernaufwand einfach sein soll, schnell wieder "perdu".
Bei einfachen Templates werde ich wohl an meiner Lösung mit dem Übersetzer, der Templates nach PHP kompiliert fest halten und im Hinblick auf so manche Widrigkeit im Verhalten einzelner Personen hierorts meinen Nutzen optimieren und also meine Lösungen entweder hier oder, falls ich ein allgemeines Interesse nicht sehe, an einer anderen Stelle präsentieren.
Hallo,
Dann ist aber der von manchem gewünschte Effekt, dass es für die Template-Ersteller im Hinblick auf den Lernaufwand einfach sein soll, schnell wieder "perdu".
Wie kommst du auf die Idee, dass jemand der Inhalte einstellen soll/will, identisch mit dem sei, der die Templates erstellt?
Gruß
Kalk
Dann ist aber der von manchem gewünschte Effekt, dass es für die Template-Ersteller im Hinblick auf den Lernaufwand einfach sein soll, schnell wieder "perdu". Wie kommst du auf die Idee, dass jemand der Inhalte einstellen soll/will, identisch mit dem sei, der die Templates erstellt?
Wie kommst Du auf die Idee, dass ich auf die Idee komme? Ich sage mit meinem Satz dazu bewusst nichts aus, weil ich weiß, dass es Fälle gibt, in denen Frontender und Backender derselbe ist UND eben solche, wo der Job zwischen Spezialisten geteilt wird.
Hallo,
Wie kommst Du auf die Idee, dass ich auf die Idee komme?
Inception!
Gruß
Kalk
@Rolf b, @Google weiß alles
In solchen Fällen würde ich Smarty vorschlagen wollen, der compiliert Templates automatisch in PHP.
Ja, Smarty ist für manches eine Lösung, insbesondere im Hinblick auf den Cache. Dann ist aber der von manchem gewünschte Effekt, dass es für die Template-Ersteller im Hinblick auf den Lernaufwand einfach sein soll, schnell wieder "perdu".
Na ja, da würde ich so nicht zustimmen. So was…
Kleine {{FARBE}} Männchen stammen vom {{PLANET}}.
…sähe in Smarty beispielsweise so aus:
Kleine {$FARBE} Männchen stammen vom {$PLANET}.
Das Ausgangsbeispiel mit {{...}} ist zudem tatsächlich etwa korrekte Twig-Syntax.
Ich sehe da keine nennenswerten Unterschiede, was den Lernaufwand angeht.
Bei einfachen Templates werde ich wohl an meiner Lösung mit dem Übersetzer, der Templates nach PHP kompiliert fest halten […].
Das kann man machen, aber im Grunde kann man dann, wenn man schon mit Kompilieren und derlei Dingen anfängt, auch gleich Twig oder Smarty nutzen. Die können im Zweifel dann eben schon noch zwei, drei Sachen mehr, die ganz praktisch sind. Ein Beispiel wären Syntax für Schleifen und Bedingungen. Zudem sind derlei Projekte infrastrukturell natürlich besser aufgestellt, was Doku oder andere Hilfestellungen angeht.
Das kann man machen, aber im Grunde kann man dann, wenn man schon mit Kompilieren und derlei Dingen anfängt, auch gleich Twig oder Smarty nutzen. Die können im Zweifel dann eben schon noch zwei, drei Sachen mehr, die ganz praktisch sind. Ein Beispiel wären Syntax für Schleifen und Bedingungen. Zudem sind derlei Projekte infrastrukturell natürlich besser aufgestellt, was Doku oder andere Hilfestellungen angeht.
Dös is ja grad des. Kaum geht was will man es auch benutzen.
Und schon ist es batzig mit dem "geringen Lernaufwand"...
@Google weiß alles
Das kann man machen, aber im Grunde kann man dann, wenn man schon mit Kompilieren und derlei Dingen anfängt, auch gleich Twig oder Smarty nutzen. Die können im Zweifel dann eben schon noch zwei, drei Sachen mehr, die ganz praktisch sind. Ein Beispiel wären Syntax für Schleifen und Bedingungen. Zudem sind derlei Projekte infrastrukturell natürlich besser aufgestellt, was Doku oder andere Hilfestellungen angeht.
Dös is ja grad des. Kaum geht was will man es auch benutzen.
Und schon ist es batzig mit dem "geringen Lernaufwand"...
Sorry, ich kann dir glaube ich nicht folgen oder weiß nicht, was du mir mitteilen möchtest. Du möchtest deine Eigenentwicklung nutzen, weil du in der Lage bist, sie zu programmieren? Und du („es“, das bayrische ich?) wirst patzig, wenn man auf die potenziellen Vorteile bestehender Standardlösungen hinweist oder nicht deiner Meinung ist, was Aspekte wie Lernaufwand angeht?
Damit weiß ich nichts anzufangen.
Freilich kannst du deine Variante natürlich gern nutzen, ich halte es aber nicht für eine sinnvolle Empfehlung für andere Leute. Das ist nicht abwertend gemeint oder so. Ich weiß nicht, wie ich es anders ausdrücken soll.
Erfahrungsgemäß landet man am Ende nicht selten bei den Standardlösungen, weil man feststellt, dass die Anforderungen doch größer sind, als man anfangs angenommen hatte, und weil man irgendwann keinen Sinn mehr darin sieht, das Rad neu zu erfinden. Etwas stumpf formuliert: Je mehr eigenen Code man produziert, desto mehr eigenen Code muss man auch pflegen. Deshalb sollte man meines Erachtens nach Möglichkeit immer erst die bestehenden Lösungen ausprobieren und nur dann selbst etwas entwickeln, wenn man begründen kann, warum man das für notwendig hält. In diesem Fall sehe ich bespielsweise das Argument „geringerer Lernaufwand“ nicht, weil bestehende Lösungen syntaktisch sogar identisch zur Eigenentwicklung sind.
PS: Ich habe es mir jetzt nicht angesehen, aber ich halte es für nicht unwahrscheinlich, dass man beispielsweise eine Eingabe für deinen Compiler erzeugen kann, die zu einer PHP-Datei führt, die syntaktisch fehlerhaft ist und damit zum Programmabbruch führt. Auch so was ist sicherlich ein Aspekt.
@Google weiß alles
Sorry, Edit-Zeitraum ist abgelaufen. Ich habe jetzt glaube ich verstanden, wie du es meintest. Tut mir leid, da war ich etwas auf dem falschen Dampfer. :( Ich hätte es noch umformuliert, aber ich denke, dass der größte Teil meiner Antwort dennoch allgemein nicht verkehrt ist.
Ich versuche mal, die These zu paraphrasieren: „Sobald das Templating komplexere Möglichkeiten unterstützt, möchte ein Anwender diese auch nutzen, was den Lernaufwand steigert.“
Zwei Punkte dazu:
Da ist erst mal die Frage, worüber wir hier eigentlich reden. Deshalb habe ich deine Antwort auch erst falsch verstanden. Ich hatte nicht auf dem Schirm, dass es sozusagen das Ziel ist, dem Anwender per Design nur ganz einfache String-Ersetzungen zur Verfügung zu stellen. Das ist natürlich in Ordnung und dafür gibt es definitiv auch Anwendungen. Ich würde auch nicht behaupten, dass es gar keinen (geschwindigkeitsbezogenen) Sinn ergibt, derlei Vorlagen nach PHP zu kompilieren. (So was ist immer ein potenzieller Risikofaktor.) Das deckt aber definitiv nicht ansatzweise alle Anwendungen für Templating ab. Ich denke, dass das in Form von deiner Umsetzung mit dem Kompilieren eher in Richtung Spezialfall geht und dass man bei simplen Ersetzungen ansonsten mit preg_replace_callback oder strtr (womöglich begleitet von Caching der fertigen Ausgabe) in Sachen Performance auch gut genug dabei ist und dass man in komplexeren Fällen dem Anwender ruhig Smarty oder Twig oder dergleichen zumuten darf, weil es bei Bedarf eben auch erweiterte Funktionalität bereitstellt. Es hängt natürlich davon ab, was man entwickelt und wie technisch versiert die Anwender sind.[1]
Ich glaube nicht, dass Nutzer so erpicht darauf sind, alle Feinheiten des genutzten Systems zu lernen. Der „normale Anwender“™ erarbeitet und notiert sich seine drei oder vier Workflows und ist im Grunde glücklich und zufrieden. Da kann man aber auch anmerken, dass es eher selten der normale Anwender ist, der sich überhaupt mit dem Editieren von Templates beschäftigt. Ich glaube, die Leute, die sich an so was rantrauen, sind eher Leute vom Fach oder zumindest Leute, von denen man als Entwickler im Normalfall eine gewisse Kompetenz erwarten kann. Die erwarten dann umgekehrt in vielen Fällen auch durchaus Funktionalität, die über das simple Verschieben von Textblöcken hinausgeht. (Die Ausnahme dazu ist, wenn die Besucher/Nutzer der Seite Templates editieren können. Etwa bei einem Blog-Anbieter. Aber das ist ein Spezialfall, denke ich. Und selbst dort kann simple Logikprogrammierung durchaus erwünscht sein.)
Was den Hinweis auf kramdown angeht: Markup-Sprachen sind schon noch mal eine andere Geschichte als Templating. Obwohl die eher vernünftige (ich hoffe? ;)) Nutzung von kramdown hier im Forum schon mein Argument stützt, dass sich die meisten Nutzer nicht mit dem Potenzial aufhalten, das eine solche Funktionalität bietet. Die Verbindung oder eine Abgrenzung von Markup-Sprache und Templating scheint mir aber ein ganz interessantes Thema zu sein. Nur fällt mir gerade nicht viel dazu ein.
Als Fazit formuliert: Ich denke nicht, dass man in normalen Fällen kompilierte Templates benötigt, wenn sich die Funktionalität darauf beschränkt, Platzhalter zu verschieben.
Noch mal meine Entschuldigung, deinen Beitrag erst falsch verstanden zu haben.
Das ist ein durchaus interessantes Thema. Meine Erfahrung dazu ist, dass es so oder so eher trübe aussieht, derlei Funktionalität für „Programmierlaien“™ bedienbar zu machen (auch wenn ich Leute da für lernfähig halte, aber lernen müssen sie auch „einfachste“ Systeme). Ich erkenne aber an, dass es gewünscht sein kann, Dinge zumindest so zu gestalten, dass sie nichts kaputt machen können (etwa durch das Ermöglichen von XSS). Wobei sich Template-Engines in Sachen Funktionsumfang wahrscheinlich auch konfigurieren lassen. Das weiß ich ohne Recherche nicht. ↩︎
@Google weiß alles
Sorry, Edit-Zeitraum ist abgelaufen. Ich habe jetzt glaube ich verstanden, wie du es meintest. Tut mir leid, da war ich etwas auf dem falschen Dampfer. :(
Ok. Angenommen.
Wobei sich Template-Engines in Sachen Funktionsumfang wahrscheinlich auch konfigurieren lassen. Das weiß ich ohne Recherche nicht.
Tja. Irgendwie geht mit freier und quelloffener Software "alles". Wenn man hinsieht, dann ist sogar das bash-Skript (inzwischen) konfigurierbar.
Etwas stumpf formuliert: Je mehr eigenen Code man produziert, desto mehr eigenen Code muss man auch pflegen.
Der Widerspruch ebenso "stumpf" formuliert: (Annahme:) Ich benutze eine dieser wunderschönen Standardlösungen. Deren Code (der viel mehr ist als ich brauche - weil der ja viel mehr können muss) wird jetzt von Dritten gepflegt und, ach, auch dauernd erweitert. Jetzt kommt irgendwann mal die Situation, dass, nehmen wir ein bekanntes Beispiel (MySQL, OpenOffice) Oracle die Firma kauft und die Entwickler wild mit dem Armen rudernd und nicht zitierfähiges fluchend wegrennen oder aus anderen Gründen das Interesse verlieren oder eben auch richtig batzige Ideen haben wodurch ich dann mein gesamtes Projekt umschreiben muss (PHP-mysql(), python 2 zu 3, ...).
Oder die Entwicker der "Kann-alles-am-besten-Libary" fummeln unbemerkt von der Community eine Sicherheitslücke rein (Joomla, Wordpress, Typo, ...) und irgendwann sind die Daten aller Mitarbeiter meiner Firma im Darknet für "zweifuffzich" zu haben - allerdings veraltet, denn ich bin keiner mehr.
Ich vertrete hier den festen und begründeten Standpunkt, dass in vielen, besonders aber den einfachen Fällen die Nutzung eigener, minimalistischer Lösungen der billigere, performantere und risokofreiere Weg ist. Und da man ja in PHP - weil es eine Skriptsprache ist - weit überwiegend nur "kleinere" Dinge erledigt (aus ein paar Daten Webseiten zusammenkrümelt) denke ich, dass diese "einfache Fälle" irgendwie die weit überwiegende Mehrheit der Fälle darstellen.
Der Widerspruch ebenso "stumpf" formuliert: (Annahme:) Ich benutze eine dieser wunderschönen Standardlösungen. Deren Code (der viel mehr ist als ich brauche - weil der ja viel mehr können muss) wird jetzt von Dritten gepflegt und, ach, auch dauernd erweitert. Jetzt kommt irgendwann mal die Situation, dass, nehmen wir ein bekanntes Beispiel (MySQL, OpenOffice) Oracle die Firma kauft [..]
MySQL ist ein schwieriges Beispiel, Du wirst wohl kaum ein DBMS selbst schreiben wollen. Außerdem: MariaDB.
Der Widerspruch ebenso "stumpf" formuliert: (Annahme:) Ich benutze eine dieser wunderschönen Standardlösungen. Deren Code (der viel mehr ist als ich brauche - weil der ja viel mehr können muss) wird jetzt von Dritten gepflegt und, ach, auch dauernd erweitert. Jetzt kommt irgendwann mal die Situation, dass, nehmen wir ein bekanntes Beispiel (MySQL, OpenOffice) Oracle die Firma kauft [..]
MySQL ist ein schwieriges Beispiel, Du wirst wohl kaum ein DBMS selbst schreiben wollen. Außerdem: MariaDB.
MySQL ist geradezu das Idealbeispiel dafür, dass "Oracle die Firma kauft und die Entwickler wild mit dem Armen rudernd und nicht zitierfähiges fluchend wegrennen". Und genau und nur dafür habe ich es höchst ausdrücklich als Beispiel genannt. Nicht jedoch dafür, "ein DBMS selbst schreiben zu wollen".
Außerdem: MariaDB.
Eben. Aber was wäre die Folge gewesen, wenn M$ oder $AP die Entwickler direkt vor der Firmenzentrale von Oracle eingesammelt und mit Geld zur Mitarbeit an deren eigener Software "gezwungen" hätte? Warum wird mir das einfach mal unterstellt um es dann schlecht zu finden?
Irgenwie habe ich also schon wieder das durch Tatsachen begründete Gefühl, dass ich ganz bewusst falsch verstanden werde. Das war doch deutlich formuliert.
Gebt mir ruhig auch dafür die -1 ... "Kritik", die sich auf wilde und grob falsche Vermutungen (eher schon vorsätzlich falsche Behauptungen) darüber bezieht, was ich äußerte, kann ich nicht wirklich ernst nehmen.
Und naturgegeben färbt das auf die Kritiker ab.
@Mitleser, @Google weiß alles:
Der Widerspruch ebenso "stumpf" formuliert: (Annahme:) Ich benutze eine dieser wunderschönen Standardlösungen. Deren Code (der viel mehr ist als ich brauche - weil der ja viel mehr können muss) wird jetzt von Dritten gepflegt und, ach, auch dauernd erweitert. Jetzt kommt irgendwann mal die Situation, dass, nehmen wir ein bekanntes Beispiel (MySQL, OpenOffice) Oracle die Firma kauft [..]
MySQL ist ein schwieriges Beispiel, Du wirst wohl kaum ein DBMS selbst schreiben wollen. Außerdem: MariaDB.
MySQL ist geradezu das Idealbeispiel dafür, dass "Oracle die Firma kauft und die Entwickler wild mit dem Armen rudernd und nicht zitierfähiges fluchend wegrennen". Und genau und nur dafür habe ich es höchst ausdrücklich als Beispiel genannt. Nicht jedoch dafür, "ein DBMS selbst schreiben zu wollen".
MySQL ist so ziemlich das einzige relevante Beispiel, das mir einfällt, in dem ein FLOSS(?)-Projekt eingekauft wurde. Und MySQL existiert weiterhin und wird auch weiterhin unter der GPLv2 vertrieben, auch wenn der Zustand sicher nicht ideal ist.
OpenOffice existiert als LibreOffice weiter und ist nicht gerade eine klassische Abhängigkeit für andere Software.
Andere Beispiele? Ich finde es okay, auf die Gefahr hinzuweisen, aber ich sehe da schnell Probleme mit der Verhältnismäßigkeit, weil es meines Wissens im Grunde keine Präzedenzfälle gibt. Zumal schlimmstenfalls eben die letzte FLOSS-Version geforkt wird.
Wenn man so was als Risiko ansieht, darf man gar keine Fremdkomponenten mehr nutzen. Das ist offenkundig nicht praktikabel, weil das natürlich bereits beim Betriebssystem anfängt. Die Furcht und das damit verbundene Argument halte ich daher letztlich für unbegründet.
Außerdem: MariaDB.
Eben. Aber was wäre die Folge gewesen, wenn M$ oder $AP die Entwickler direkt vor der Firmenzentrale von Oracle eingesammelt und mit Geld zur Mitarbeit an deren eigener Software "gezwungen" hätte? Warum wird mir das einfach mal unterstellt um es dann schlecht zu finden?
Irgenwie habe ich also schon wieder das durch Tatsachen begründete Gefühl, dass ich ganz bewusst falsch verstanden werde. Das war doch deutlich formuliert.
Schreib ruhig dein eigenes DBMS, wenn du sonst nicht ruhig schlafen kannst. Aber das ist auf sehr vielen Ebenen Quatsch, und das ist vor allem auch nichts, was man Fragestellern empfehlen sollte. Das ist mein wesentliches „Problem“ mit deinen Antworten. Du vertrittst Standpunkte, die hochgradig „ideologisch“ geprägt sind und die nicht in dem Sinne „praktikabel“ oder „angemessen“ sind. Das ist kein guter Rat für Fragesteller, auch wenn es für dich Sinn ergeben mag. Du vertrittst nun mal nicht den „Normalfall“. Du schneidest sie damit mehr oder weniger gezielt von der Restwelt der Entwickler ab. Das empfinde ich als sehr kontraproduktiv und als etwas, dem man relativierend widersprechen sollte oder sogar muss.
Gebt mir ruhig auch dafür die -1 ... "Kritik", die sich auf wilde und grob falsche Vermutungen (eher schon vorsätzlich falsche Behauptungen) darüber bezieht, was ich äußerte, kann ich nicht wirklich ernst nehmen.
Und naturgegeben färbt das auf die Kritiker ab.
Ich habe dir noch kein -1 gegeben, aber ich möchte dich dennoch ersuchen, Leute nicht zu den Lösungen mit ~1 Nutzern zu verleiten, wenn es anerkannte Alternativen mit dem Zehntausendfachen an Nutzern gibt. Da passt die Verhältnismäßigkeit nicht. Du kannst deine Variante gern präsentieren (ich finde das durchaus interessant), aber es ist einfach nicht richtig, so zu tun, als ob deine Lösung die bessere wäre. Das ist kein haltbarer Standpunkt.
Irgenwie habe ich also schon wieder das durch Tatsachen begründete Gefühl, dass ich ganz bewusst falsch verstanden werde. Das war doch deutlich formuliert.
Ich beschränke mich auf den Kern und zwei Sätze:
Schreib ruhig dein eigenes DBMS, wenn du sonst nicht ruhig schlafen kannst. Aber das ist auf sehr vielen Ebenen Quatsch, und das ist vor allem auch nichts, was man Fragestellern empfehlen sollte.
WOW!
Das muss man erst mal hinkriegen, unter meiner Aussage
MySQL ist geradezu das Idealbeispiel dafür, dass "Oracle die Firma kauft und die Entwickler wild mit dem Armen rudernd und nicht zitierfähiges fluchend wegrennen". Und genau und nur dafür habe ich es höchst ausdrücklich als Beispiel genannt. Nicht jedoch dafür, "ein DBMS selbst schreiben zu wollen".
allerhand Zeug zu notieren und dann zu formulieren:
Schreib ruhig dein eigenes DBMS, wenn du sonst nicht ruhig schlafen kannst.
Ja. Reichte wohl nicht - also das dann noch mit mit der Vorhaltung garnieren, ich hätte eben dieses Vorgehen dem Fragestellern empfohlen:
Aber das ist auf sehr vielen Ebenen Quatsch, und das ist vor allem auch nichts, was man Fragestellern empfehlen sollte.
Wenn das dann noch unter der von mir gewählten Überschrift "Klare Ansage: Lesen und keine falschen Behauptungen aufstellen" stattfindet bin ich schon zu recht sauer - oder?
@Google weiß alles
Okay, mal so als Denkanstoß:
Hier eine Liste der von mir bemerkten Tippfehler in myTemplateToPHP.sh, Version 1.1.2:
replacementrRightreplacementrRightreplacementrRightYoy, sedileEine Liste der bemerkten Logikfehler oder inhaltlichen Fehler:
htmlspecialchars benötigt den Parameter ENT_QUOTES (für Platzhalter in HTML-Attributen) und eigentlich auch noch eine encoding-Angabe (Hintergrund)..txt endet.hasErrors könnte durch eine vorherige Eingabedatei den Wert 1 haben, wird hier aber auf 0 zurückgesetzt. Fehler werden dadurch potenziell verdeckt.hasErrors könnte nicht initialisiert sein.Bonus:
In die Ausgabe kann beliebiger PHP-Code injiziert werden.
Für htmlSafeMode="yes":
Eingabe:
foo {{ '])?> <?php var_dump(filemtime(__FILE__)); ?> <?=($tpl[' }} bar
Ausgabe:
foo <?=htmlspecialchars( $tpl[' '])?> <?php var_dump(filemtime(__FILE__)); ?> <?=($tpl[' '] );?> bar
Für htmlSafeMode="no":
Eingabe:
foo {{ ']?> <?php var_dump(filemtime(__FILE__)); ?> <?=$tpl[' }} bar
Ausgabe:
foo <?=$tpl[' ']?> <?php var_dump(filemtime(__FILE__)); ?> <?=$tpl[' '];?> bar
Statt var_dump(filemtime(__FILE__)); kann dort natürlich beliebiger Code stehen.
Das war jetzt ein Code Review mit den offensichtlichen Problemen in 52 Zeilen Code (inklusive Leerzeilen und Kommentare). Das dauerte länger als 3 Sekunden, war aber dafür vermutlich auch ergiebiger.
Wobei sich Template-Engines in Sachen Funktionsumfang wahrscheinlich auch konfigurieren lassen. Das weiß ich ohne Recherche nicht.
Tja. Irgendwie geht mit freier und quelloffener Software "alles". Wenn man hinsieht, dann ist sogar das bash-Skript (inzwischen) konfigurierbar.
Ja, wenn man bloß mal hinsehen würde, würde man sicher so einige Fehler entdecken. :)
(Nur am Rande und ohne Frotzelei, weil ich es richtig finde, das zu erwähnen: Auch dein Lizenztext enthält so einige grammatikalische Fehler. Den solltest du dir noch mal genau ansehen. Ich stimme ansonsten zu, dass die Lizenz eine Nutzung deines Codes leider quasi unmöglich macht, wenn man das Thema Lizenzen halbwegs ernst nimmt. Die Unwägbarkeiten sind nicht praktikabel und manche Aspekte sind unverständlich.)
Etwas stumpf formuliert: Je mehr eigenen Code man produziert, desto mehr eigenen Code muss man auch pflegen.
Der Widerspruch ebenso "stumpf" formuliert: (Annahme:) Ich benutze eine dieser wunderschönen Standardlösungen. Deren Code (der viel mehr ist als ich brauche - weil der ja viel mehr können muss) wird jetzt von Dritten gepflegt und, ach, auch dauernd erweitert. Jetzt kommt irgendwann mal die Situation, dass, nehmen wir ein bekanntes Beispiel (MySQL, OpenOffice) Oracle die Firma kauft und die Entwickler wild mit dem Armen rudernd und nicht zitierfähiges fluchend wegrennen oder aus anderen Gründen das Interesse verlieren oder eben auch richtig batzige Ideen haben wodurch ich dann mein gesamtes Projekt umschreiben muss (PHP-mysql(), python 2 zu 3, ...).
Das Risiko besteht allerdings immer bei so ziemlich allem. Die PHP-Entwickler könnten auch irgendwann mal auf die Idee kommen, beispielsweise die array_*-Funktionen auszutauschen. Zu inkompatiblen Änderungen an htmlspecialchars, die theoretisch durchaus auch dein Bash-Script betreffen würden, habe ich oben schon was verlinkt. Selbst die Bash-Syntax ist nicht in Stein gemeißelt. Oder die von sed. Oder die Frage, ob sed oder mktemp irgendwann nicht mehr paketiert sein könnten.
Nachträgliche Pflege ist im EDV-Umfeld ein Faktor, mit dem so oder so kalkuliert werden muss. Es gibt in der Hinsicht (leider?) den idealen Code nicht. Die Lebenszyklen sind endlich.
Oder die Entwicker der "Kann-alles-am-besten-Libary" fummeln unbemerkt von der Community eine Sicherheitslücke rein (Joomla, Wordpress, Typo, ...) und irgendwann sind die Daten aller Mitarbeiter meiner Firma im Darknet für "zweifuffzich" zu haben - allerdings veraltet, denn ich bin keiner mehr.
Nun ja… Das kann theoretisch auch jeder Entwickler eines Pakets einer Linux-Distribution tun. Ähnlich wie mein Kommentar zum letzten Aspekt. Das kann auch jeder Entwickler proprietärer Software tun. Nur ist es bei denen nicht mal theoretisch nachvollziehbar, weil der Code nicht offen einsehbar ist.
Es ist letztlich so, dass der Free-Software-Kosmos oder der Software-Kosmos generell auf Vertrauen basiert. Das kann man auch nicht so einfach rauskürzen, weil kein einzelner Mensch Millionen an Codezeilen überwachen kann. (Führt jetzt zu weit, aber ich werfe da mal den Begriff „bugdoor“ in den Raum.)
Dennoch gibt es bei dem Thema durchaus Aspekte in Sachen Gewährleistung und dergleichen. Ich weiß von Unternehmen, die auf der Grundlage durchaus die Nutzung externer Bibliotheken verbieten. Eine gewisse Paranoia oder Vorsicht ist da sicher nicht verkehrt. Die muss man aber gegenüber praktischen Aspekten abwägen. Zudem garantiert eben auch niemand, dass der „in house“-Code oder der Code, den man den Dienstleister hat machen lassen, qualitativ besser ist. Das ist letztlich auch eher der Punkt, dass die Kunden jemanden greifbar haben wollen, der eine Gewährleistungspflicht erfüllt und gegebenenfalls nachbessert.
Es ist ein offenes Geheimnis, dass der meiste Code… nicht so toll ist.
Ich vertrete hier den festen und begründeten Standpunkt, dass in vielen, besonders aber den einfachen Fällen die Nutzung eigener, minimalistischer Lösungen der billigere, performantere und risokofreiere Weg ist.
Ich will nicht darauf rumreiten, aber ich habe oben demonstriert, dass du im Schnitt alle 5-10 Zeilen (nicht mal SLOC-Zeilen) einen eindeutigen Fehler gemacht hast und dass du bei deinem Ansatz auch mindestens ein konzeptionelles Problem hast, weil du das Einfügen beliebigen PHP-Codes gestattest.
Das ist höchstens security through obscurity, weil sich niemand die Mühe macht, genau dein System anzugreifen, wenn man mit einem WordPress-Hack gleich – keine Ahnung – 75 Millionen Seiten attackieren könnte. Dein Code ist nicht unwahrscheinlich trotzdem viel schlechter als der von WordPress. (Ironischerweise ist das ein Konzept, was dennoch irgendwie sogar funktioniert. Aber sobald du ein einigermaßen lohnenswertes Ziel bist, trägt dir dann halt doch irgendein Hacker mal die Daten raus. Das potenzielle Risiko ist trotzdem immer vorhanden, es wird nur nicht realisiert. Wenn du auf dem Land wohnst, brauchst du dein Haus nicht abzuschließen, weil dir halt keiner an der Tür rüttelt.)
Und da man ja in PHP - weil es eine Skriptsprache ist - weit überwiegend nur "kleinere" Dinge erledigt (aus ein paar Daten Webseiten zusammenkrümelt) denke ich, dass diese "einfache Fälle" irgendwie die weit überwiegende Mehrheit der Fälle darstellen.
Da müsste ich jetzt eigentlich weiter ausholen. Ein Aspekt ist jedenfalls: Wenn du einen einfachen Fall hast, brauchst du auch keine kompilierten Templates.
Kann wieder nicht mehr editieren. (20 Minuten reichen für mich nicht. Dazu bin ich zu exakt/mache ich zu viele Fehler. ;))
- Zeile 36:
hasErrorskönnte durch eine vorherige Eingabedatei den Wert 1 haben, wird hier aber auf 0 zurückgesetzt. Fehler werden dadurch potenziell verdeckt.
Wobei es eine Fehlerausgabe gibt. Einwandfrei ist die Logik an der Stelle meines Erachtens dennoch nicht, weil hasErrors zurückgesetzt wird, obwohl der Wert später noch abgefragt wird.
- Zeile 36:
hasErrorskönnte durch eine vorherige Eingabedatei den Wert 1 haben, wird hier aber auf 0 zurückgesetzt. Fehler werden dadurch potenziell verdeckt.
Naja. Fehler werden nicht verdeckt, aber es kann am Ende nicht mehr die Datei mit Regeln für sed angesehen werden. Trotzdem ist es natürlich FALSCH. Die Zeile hasErrors='0'; habe ich also gelöscht.
Danke für den Hinweis.
@Google weiß alles
Okay, mal so als Denkanstoß:
Hier eine Liste der von mir bemerkten Tippfehler in
myTemplateToPHP.sh, Version 1.1.2:
- Zeile 13:
replacementrRight- Zeile 16:
replacementrRight- Zeile 26:
replacementrRight
Ok. Sind Tippfehler, die sich aber im Programmablauf nicht bemerkbar machten, weil ich an jeder Stelle replacementrRight statt replacementRight notierte. Hab es aber geändert und weil es tatsächlich Tippfehler sind möchte ich nicht verfehlen, mich für den Hinweis zu bedanken.
- Zeile 49:
Yoy,sedile
Ok. 'Yoy' ist ein Tippfehler (Es muss natürlich "You" heissen!), der sich aber im Programmablauf nicht bemerkbar machte, weil er nur als Text in der informativen Ausgabe ab Ende auftritt. Und das nur nur wenn Fehler aufgetreten sind.
Eine Liste der bemerkten Logikfehler oder inhaltlichen Fehler:
- Zeile 15: XSS-Angriff möglich.
htmlspecialcharsbenötigt den ParameterENT_QUOTES(für Platzhalter in HTML-Attributen) und eigentlich auch noch eineencoding-Angabe (Hintergrund).
Mein. Oder Ja. Das Skript kann natürlich nur das Template von Text nach PHP übersetzen. Es entsteht ein Template. Wenn man es ganz genau nimmt, dann ist es eine Frage des konkret geplantes Ablaufes, ob die, für die Ausgabe angezeigten Änderungen an Variableninhalten im Template definiert werden oder im Programm und zwar dort, wo die Daten unter Beachtung der jeweiligen Quelle in den hash "$TPL" eingefügt werden. Eine allgemeingültige Anforderung ist hier nicht formulierbar.
Das gilt auch für den Zeichensatz. Der wird "eher nicht" im Template festgelegt, sondern zentraler. Trotzdem: Danke für den Hinweis.
- Zeile 30: Überschreibt nachfolgend vermutlich die Eingabedatei, falls diese nicht auf
.txtendet.
Nein. In Zeile 30 wird nur der Name der Ausgabedatei ermittelt. Und richtig: Wenn die Eingabedatei auf .php endet, dann würde diese in Zeile 33 überschrieben, genau genommen geleert. Das ist zwar auch eine Frage der Vereinbarung, aber Du hast Recht, das kann man einfach verhindern. Kommt in die Version 1.1.3. - Danke für den Hinweis.
- Zeile 36:
hasErrorskönnte durch eine vorherige Eingabedatei den Wert 1 haben, wird hier aber auf 0 zurückgesetzt. Fehler werden dadurch potenziell verdeckt.
- Zeile 48:
hasErrorskönnte nicht initialisiert sein.
Das ist in genau einem Fall nicht initialisert, nämlich wenn keine Eingabedatei existiert. Das ist aber kein Fehler im Programmablauf, also wird nichts "geflaggt", also wird auch kein Fehler - der ja nicht auftrat - gemeldet. Trotzdem: Danke für den Hinweis.
In die Ausgabe kann beliebiger PHP-Code injiziert werden.
Das ist NUR unter der Annahme richtig, dass die Inhalte in $TPL 1:1 'usergeneriert' sind, z.B. durch Übernahme aus GET, POST, COOKIE, ... (oder auch immer.) Wie schon geschrieben kann und sollte man das an anderer Stelle regeln, nämlich bei der Übernahme in $TPL. Trotzdem: Danke für den Hinweis.
Für
htmlSafeMode="yes":
Eingabe:
foo {{ '])?> <?php var_dump(filemtime(__FILE__)); ?> <?=($tpl[' }} barAusgabe:
foo <?=htmlspecialchars( $tpl[' '])?> <?php var_dump(filemtime(__FILE__)); ?> <?=($tpl[' '] );?> bar
Ich habe das mit
$tpl['FARBE'] = 'foo {{ \'])?> <?php var_dump(filemtime(__FILE__)); ?> <?=($tpl[\' }} bar';
in webseite.php versucht und das Template mit htmlSafeMode="no" übersetzt.
Die Ausgabe lautet:
Kleine foo {{ '])?> <?php var_dump(filemtime(__FILE__)); ?> <?=($tpl[' }} bar Männchen stammen vom Mars.
Hast Du eventuell den visuellen Kontextwechsel durch die Darstellung im Browser nicht beachtet? Falls nicht zeige mir, was Du GENAU gemacht hast und ich entscheide dann ob es ein Future oder ein Bug ist.
Für
htmlSafeMode="no":
Eingabe:
foo {{ ']?> <?php var_dump(filemtime(__FILE__)); ?> <?=$tpl[' }} barAusgabe:
foo <?=$tpl[' ']?> <?php var_dump(filemtime(__FILE__)); ?> <?=$tpl[' '];?> bar
Das habe ich mit
$tpl['FARBE'] = 'foo {{ \']?> <?php var_dump(filemtime(__FILE__)); ?> <?=$tpl[\' }} bar';
versucht und das Template mit htmlSafeMode="yes" übersetzt.
Ergebnis nach Aufruf mit php webseite.php:
foo {{ '])?> <?php var_dump(filemtime(__FILE__)); ?> <?=($tpl[' }} bar
Nun, ich weiß ja nicht was Du vorhast. Aber so lange man das Ergebnis der Vereinigung von Daten und Template, also die Ausgabe, nicht nochmal von PHP interpretieren lässt (was wohl eines Probleme von Wordpress ist oder war) kann hier nichts passieren. Es sei denn natürlich, die Browser stellen gänzlich unerwartet von Javascript auf PHP um oder jemand holt die resultierende Webseite und lässt diese dann mit PHP interpretieren. Was auch ziemlich ungewöhnlich ist.
Das war jetzt ein Code Review mit den offensichtlichen Problemen in 52 Zeilen Code (inklusive Leerzeilen und Kommentare). Das dauerte länger als 3 Sekunden, war aber dafür vermutlich auch ergiebiger.
Danke für die Tippfehler und Hinweise. Was in Deiner Darstellung wie ein "richtiger" Fehler aussah konnte ich nicht nachvollziehen.
Falsch notiert:
versucht und das Template mit `htmlSafeMode="yes"` übersetzt.
Muss heißen:
versucht und das Template mit `htmlSafeMode="no"` übersetzt.
Der Rest bleibt:
Ergebnis nach Aufruf mit php webseite.php:
foo {{ '])?> <?php var_dump(filemtime(__FILE__)); ?> <?=($tpl[' }} barNun, ich weiß ja nicht was Du vorhast. Aber so lange man das Ergebnis der Vereinigung von Daten und Template, also die Ausgabe, nicht nochmal von PHP interpretieren lässt (was wohl eines Probleme von Wordpress ist oder war) kann hier nichts passieren. Es sei denn natürlich, die Browser stellen gänzlich unerwartet von Javascript auf PHP um oder jemand holt die resultierende Webseite und lässt diese dann mit PHP interpretieren. Was auch ziemlich ungewöhnlich ist.
Vorab: Die Prämisse(!) "geringer Lernaufwand" hatte Tabellenkalk in die Diskussion eingeführt.
Und schon ist es batzig mit dem "geringen Lernaufwand"...
Und du („es“, das bayrische ich?) wirst patzig, wenn man auf die potenziellen Vorteile bestehender Standardlösungen hinweist oder nicht deiner Meinung ist, was Aspekte wie Lernaufwand angeht?
Nein.
Wenn eine Templating-Engine einmal verfügbar ist, setze ich die auch konsequent ein und bin überzeugt davon dass beispielsweise sowas
$(descr).text(xr('Zugriffe am @dat@: @cnt@, sql: @sql@', {
dat: dat,
cnt: jobj.cnt,
sql: jobj.sql
}));
besser lesbar ist als Stringverkettungen die in PHP wie JS besonders ekelhaft sind ;)
PS: Einmal Template immer Template.
# am Server gleich die richtige Datenstruktur geholt
my $slice = $dbh->selectall_arrayref("select * from log where date(dat) = date(now()) order by dat desc", {Slice => {}});
$self->{CONTENT} = $json->encode({ tbody => $slice, cnt => scalar(@$slice) });
// befüllt in JS ne ganze Tabelle
var tt = $('#tbodytt').html();
var jobj = JSON.parse(this.response);
$('#tbody').html( xr(tt, jobj) );
Lieber Jörg,
<!-- template: file template.php //--> Kleine <?=$tpl['FARBE'];?> Männchen stammen vom <?=$tpl['PLANET'];?>.
dieser Code setzt voraus, dass er von PHP geparst wird. Schreibt ein Autor (lies: Inhalte-Hineinschreiber, NICHT Programmierer!) syntaktisch falsch, entstehen Syntaxfehler, die die Ausführung des gesamten Prozesses ins Nirvana schicken kann, was zu einer dauerhaften Unverwendbarkeit der betroffenen Seite führt.
Will man das immer?
Auch in meinen Projekten notiere ich {#irgendein-text} und {$irgendein-wert}, obwohl ich selbst derjenige bin, der beides betreut. Wozu riskieren, dass meine Anwendung an dieser Stelle wegen nichtiger Syntaxprobleme stecken bleibt? Und warum sollte ich die Ausgabedaten von PHP parsen lassen? Die sind doch (in aller Regel) CSS/HTML/JS und nicht (schon wieder) PHP!
Liebe Grüße,
Felix Riesterer.
Will man das immer?
Ich habe die Vorteile dieser Vorgehensweise beschrieben. Nicht behauptet, dass man das immer will. Manchmal macht halt Unsinn im Sinne eines Kompromisses.
Und warum sollte ich die Ausgabedaten von PHP parsen lassen?
Ich wiederhole:
Es ist schneller, es gibt praktikable Fehlermeldungen (Notizen), Editoren zeigen das nativ in PHP geschriebene Template "schön bunt" an ...
eine allgemeine Frage. Was sind das {{ ... }} für platzhalter, doppelt geschweifte klammern???
Die Klammern sind charakteristisch für mustache – eine rein deklarative und logikfreie Templating-Sprache mit Implementierungen in zahlriechen Programmiersprachen.
@.MB, @1unitedpower
eine allgemeine Frage. Was sind das {{ ... }} für platzhalter, doppelt geschweifte klammern???
Die Klammern sind charakteristisch für mustache – eine rein deklarative und logikfreie Templating-Sprache mit Implementierungen in zahlriechen Programmiersprachen.
Im PHP-Bereich kennt man es von zumindest Twig. Die Begrenzer sind aber oftmals frei definierbar, was eine konkrete Zuordnung ohne weiteren Kontext noch mehr unmöglich macht als ohnehin schon. :)
moinmoin, Die Verwendung von Klammern "(),{}" in Programmierung in C, JavaScript, SPS, etc:
function(Bedingung) {
wenn erfüllt dann mache diese Anweisung;
und diese nächste Anweisung;
und noch eine Anweisung;
}
Es lassen sich beliebig viele Funktionen - x-te Funktion in einer Anweisung - ineinander verschachteln, sodass viele geschweifte Klammern (meistens) am FunktionsENDE abgeschlossen müssen:
function(Bedingung1) {
if(Bedingung2) {
wenn "Bedingung1 UND 2" erfüllt dann mache diese Anweisung;
} else {
wenn "Bedingung1" UND NICHT "Bedingung2" erfüllt dann mache jenes; und das hier; und noch dieses;
}
}
vlg KoJoTe / KTElektronik
Hallo,
meine frage zielte auf was anderes ab, das hier schon deutlich unterbreitet wurde. Du hast mich wohl, wie viele in dieser Runde, falsch verstanden. Liegt nicht an dir sonder an mir. Aber gute Erklärung.
vgl MB