![\"\"](\"https://journal.3960.org/posts/2018-09-19-umstieg-auf-microsoft-visual-studio-code/visual-code-400x225.png\")
A fundamental principle of building (web) applications is to have a strict separation between logic and output – at least if your goal as a programmer is to stay sane. For outputting stuff most often there is a simple (template) language to prevent mixing too much logic into your templates.
\nFor PHP template engines like Twig or Smarty solve the outputting part. But do we really need a template engine? Is it possible that PHP (without any additional libraries) is quite sufficient to do templating?
", "content_encoded": "A fundamental principle of building (web) applications is to have a strict separation between logic and output – at least if your goal as a programmer is to stay sane. For outputting stuff most often there is a simple (template) language to prevent mixing too much logic into your templates.
\nFor PHP template engines like Twig or Smarty solve the outputting part. But do we really need a template engine? Is it possible that PHP (without any additional libraries) is quite sufficient to do templating?
\n\nThe main idea of template engines is:
\nif, while or for are more simple to use in a template engine.A perfect example for this philosophy is the template engine Mustache: It only contains a minimum of required methods in order to reduce complexity.
\nBut do we really need the overhead of a proper template engine? Or is it possible to use plain PHP for our templating needs, without adding dependencies like template engines to our project?
\nActually PHP has good capabilities to do templating – its founding idea revolves around templating, as a matter of fact.
\nIt is common practice to put all your templates into a separate folder, and append a common file extension to all template files. For example Symfony with Twig puts all templates into a directory called /templates and use the file extension .twig.
Actually there is nothing stopping us from using the same /templates directory for our templates. As file extension we are using (like Twig and to keep our mental health):
| Template output | \nFile extension | \n(MIME-type) | \n
|---|---|---|
| HTML file | \n*.html.php | \ntext/html | \n
| XML file | \n*.xml.php | \ntext/xml or application/xml | \n
| JSON file | \n*.json.php | \napplication/json | \n
| Text file | \n*.txt.php | \ntext/plain | \n
| CSV file | \n*.csv.php | \ntext/csv | \n
This list is easily extended be even more MIME-types and corresponding file extensions. Important for us is that all files end with .php, so our code editor knows how to handle these files. This also secures the files if by mistake these files get called directly by a web server; files ending with .php will be executed as PHP, and their PHP secrets will be compiled and not shown to a world-wide audience.
It is good custom to name your template after the controller calling it. Accordingly a HTML template for an index-controller will be index.html.php, for an user-controller user.html.php. The XML template for the index-controller becomes index.xml.php.
Templates not attached to a controller (called snippets or partials) will be prefixed with a _, e.g. _meta.html.php. The purpose of these files will be explained later on.
We will take advantage of the fact that PHP returns every line of code not enclosed in PHP tags (<?php ?>) unaltered back to the browser. That allows us to concentrate on building our beautiful template output:
<!DOCTYPE html>\n<html xmlns="http://www.w3.org/1999/xhtml" lang="en">\n<head>\n</head>\n<body>\n <!-- I am valid PHP -->\n</body>\nThe most important task of templates is to output variables prepared by the controller. Like in every template language we open up a instruction block and execute a function for outputting a variable.
\n<!-- Bad idea -->\n<div><?php echo($title) ?></div>\nPHP kindly allows for shortening the output instruction:
\n<!-- Still a bad idea -->\n<div><?= $title ?></div>\nBut actually the above examples are very bad ideas, because both ignore quoting / escaping – a core function of any good template engine, because only this secures variable output against malicious intentions. Look at the above examples and imagine some HTML tags (or characters like a single <) inside $title – as you can see these will be embedded into the HTML output. In most cases this is undesirable, possibly breaking your site or (even worse) allowing attackers to make your site send harmful HTML to your visitor's browsers. Want to see an example?
<!-- See, a bad idea -->\n<div><?= $_GET['search'] ?></div>\nBut PHP has you covered: htmlspecialchars converts any string to safe HTML (or XML, for that matter). Characters like <, > or " will be safely encoded:
<!-- Better idea -->\n<div><?= htmlspecialchars($title) ?></div>\nBecause this main method of outputting variables will become tedious to write, we are introducing an alias for htmlspecialchars – the beginning of the world's smallest PHP template engine:
// Template.php\n\n/**\n * Alias for `htmlspecialchars`\n */\nfunction html($s): string\n{\n return htmlspecialchars($s);\n}\nThis function shortens our work to convert variables and will be our new main function to send variable content back to the browser:
\n<!-- Best idea -->\n<div><?= html($title) ?></div>\nPHP offers even more function for quoting / escaping. There is a function for encoding query parameters used in URLs, quoting characters like # or &: urlencode. These can be easily combined with our html function:
<a href="https://www.example.com?id=<?= html(urlencode($id)) ?>">Test</a>\nSometimes we also have to convert our PHP variables to JavaScript variables. Not explicitly build for that purpose but highly recommendable is a function called json_encode. It actually converts the given variable to JSON – which is also valid JavaScript. Even better the function also converts PHP arrays and objects to JavaScript arrays and objects:
<script>\nvar data = <?= json_encode($data) ?>;\n</script>\nThe most important control structure in templates are conditions, with your best friend if to be mentioned first. But „pure“ PHP with its curly brackets used in conjunction with if tends to make matters confusing in your template, making it hard to see where your conditional block ends:
<?php if (!empty($title)) { ?>\n <div><?= html($title) ?></div>\n<?php } ?>\nDo not despair, PHP has an alternative syntax for controls structures tailored for templating tasks. Instead of starting a block via { a simple : is used. And instead of ending a block via } something like end...; will be used:
<?php if (!empty($title)): ?>\n <div><?= html($title) ?></div>\n<?php endif ?>\nYour if-conditions can use any operators and functions known to PHP. One of your most important conditions in templating will be a check if a given variable has content to output. This test is simply executed by using !empty or isset.
Of course there is also else and elseif available:
<?php if (!empty($results)): ?>\n <h4>We have found <?= html(count($results)) ?> results.</h4>\n<?php else: ?>\n <h4>Sorry, we have found no results.</h4>\n<?php endif ?>\nThen there are lists and tables in your templates. With PHP loops your are able to iterate over an PHP array to output lists and tables. Lucky for you there is also an alternate syntax for looping control structures:
\n<?php if (!empty($list)): ?>\n <ul>\n <?php foreach($list as $index => $item): ?>\n <li><?= html($item) ?></li>\n <?php endforeach ?>\n </ul>\n<?php endif ?>\nThis syntax does a proper job for for, foreach or while:
<h4>Lottery numbers</h4>\n<ol>\n <?php for ($i = 1; $i <= 49; $i++): ?>\n <li>\n <input type="checkbox" name="lottery_<?= html($i) ?>" id="lottery_<?= html($i) ?>" value="1" />\n <label for="lottery_<?= html($i) ?>"><?= html($i) ?></label>\n </li>\n <?php endfor ?>\n</ol>\nPartial templates present in multiple controllers (like a header, footer or navigation) are called… partials (doh!) or snippets. These partials are prefixed with a single _, for example _header.xml.php.
These partials or snippets can be embedded into other templates by PHP's very own include instruction:
<!DOCTYPE html>\n<html xmlns="http://www.w3.org/1999/xhtml" lang="en">\n<head>\n <?php include('_meta.html.php') ?>\n</head>\n<body>\n <?php include('_header.html.php') ?>\n ...\n <?php include('_footer_.html.php') ?>\n</body>\nYou never would have guessed, but PHP also handles translations! The Gettext library is included in PHP and allows to translate strings, which Gettext will look up in a dictionary you are able to build. If a translation is found, Gettext will return it to PHP.
\nMost important for translations is to tell PHP the language / locale you are using. This is done via setlocale:
setlocale(LC_MESSAGES, 'de_DE'); // German in Germany\nsetlocale(LC_MESSAGES, 'en_GB'); // English in Great Britain\nThis also switches to the correct format for numbers and dates in the given language, as well as using the correct date terms for months and weekdays.
\nThe strings you want translated are passed to the gettext / _ function:
<!-- translate to 'Guten Morgen!' -->\n<h4><?= html(_('Good morning!')) ?></h4>\nThe required dictionaries to translate your strings can be created by yourself. The required PO- and MO-files can be created using programmes like Poedit. Poedit also offers to search your whole project for translatable strings to automatically add them to your dictionaries.
\nIf your happen to add variables to your translatable strings things can get a little hairy. This somewhat complex construction allows for a translatable string to also work with variables:
\n<div><?= html(vsprintf(_('There are %d results'), [$count])) ?></div>\nSo here is our next alias to be added to our simple template engine: A shortcut for outputting translatable strings mixed with variables.
\n// Template.php\n\n/**\n * Alias for `vsprintf`, but with HTML escaping and translation\n */\nfunction _html(string $format, array $args = []): string\n{\n return htmlspecialchars($args\n ? vsprintf(_($format), $args)\n : _($format)\n );\n}\n…which makes writing translatable strings mixed with variables somewhat less tedious:
\n<h4><?= _html('Good morning!') ?></h4>\n<div><?= _html('There are %d results', [$count]) ?></div>\nIt is very helpful for developers as well as template builders alike to have a look into complex variable constructs for debugging purposes – think of big objects or arrays to traverse. PHP offers print_r and var_dump / var_export for this purpose. These functions are helpful, but not in HTML as they do not produce any line breaks, dumping all your structured data into a single line. Again our little template engine comes to the rescue with a small shortcut:
// Template.php\n\n/**\n * HTML dumper für PHP variables\n */\nfunction debug($mixed, bool $extended = false): void\n{\n echo('<pre class="debug" style="margin: 1em 0; border: 1px solid red; background: #fee; color: #000; padding: 1em;">');\n echo(htmlspecialchars($extended\n ? var_export($mixed, true)\n : print_r($mixed, true)\n ));\n echo('</pre>');\n}\nThis allows for complex variables to be dumped in a readable manner:
\n<?php debug($data) ?>\nWhile your at it, you might consider using console.log for debugging output in the console of your browser.
PHP was build to output HTML. This works by PHP telling the browser that the MIME-type of the document it is sending is text/html. But actually PHP is perfectly capable to send any other MIME-type header. The function header allows PHP to send custom headers to your visitor's browsers, replacing default headers while your at it.
The header used to set the MIME-type is Content-Type. So it is perfectly possible for PHP to send any conceivable MIME-type.
For XML we choose the file extension .xml.php, for example in sitemap.xml.php. This template does not differ very much from a standard HTML template, and uses the same quoting / encoding routines. We just have to send a different Content-Type header and we are serving proper XML:
<?php header('Content-Type: text/xml'); ?>\n<urlset>\n <?php foreach($urls as $url): ?>\n <url>\n <loc><?= html($url) ?></loc>\n </url>\n <?php endforeach ?>\n</urlset>\nOutputting JSON is also quite simple with PHP. For this MIME-type we are using the file extension .json.php (like in feed.json.php) and need to set the correct Content-Type. To properly use quoting / escaping the inbuilt PHP function json_encode is very helpful, as it converts even complex PHP variables into structured JSON output:
<?php\n header('Content-Type: application/json');\n echo(json_encode($data));\nIf you like your JSON's source to look nice, there is also a parameter called JSON_PRETTY_PRINT for json_encode:
<?php\n header('Content-Type: application/json');\n echo(json_encode($data, JSON_PRETTY_PRINT));\nActually PHP's json_encode precisely converts PHP variable types to the matching JSON types. A PHP integer will be a JSON integer, a PHP string will be a JSON string. So note the difference between 1 and „1“.
The examples above for fetching templates and setting the correct MIME-type can be solved with a general switch block:
// e.g. $template = 'index';\n// e.g. $contentType = 'html';\n\nswitch ($contentType) {\n case 'xml':\n header('Content-Type: text/xml');\n break;\n case 'json':\n header('Content-Type: application/json');\n break;\n case 'txt':\n header('Content-Type: text/plain');\n break;\n case 'csv':\n header('Content-Type: text/csv');\n break;\n default:\n $contentType = 'html';\n break;\n}\n\n$templateFilename = __DIR__ . '/templates/' . $template . '.' . $contentType . '.php';\nrequire($templateFilename);\nEVery PHP project needs to have a clean separation between logic and output – but not always you will need a template engine like Twig or Smarty for this separation. Common off-the-shelf PHP (with few small helpers) can be a simple, fuss-free alternative for templating.
\nSo here it is, our small manual of the most important PHP functions for templating:
\n| Function | \nAlias | \nDescription | \n
|---|---|---|
htmlspecialchars | \nhtml | \nHTML escaping | \n
urlencode | \n- | \nURL escaping | \n
json_encode | \n- | \nJSON/JavaScript escaping | \n
setlocale | \n- | \nSet language / locale for translation | \n
gettext / _ | \n_html | \nOutputting translation | \n
strftime | \n- | \nOutput localized date format | \n
localeconv | \n- | \nGet number format for current locale | \n
printf | \n_html | \nOutput formatted variables in string | \n
nl2br | \n- | \nConvert line breaks to <br /> | \n
implode | \n- | \nJoins array members to a single string | \n
var_dump | \ndebug | \nDump PHP variables | \n
header | \n- | \nChange Content-Type in browser | \n
The only thing missing from PHP is template inheritance, like in Twig's template inheritance or Smarty's template inheritance. Also have a look at CSS-Trick's comparison of template engines.
\nEs gibt auch eine deutsche Version von diesem Artikel, „Die kleinste PHP-Templating-Engine der Welt“.
Die Trennung von Logik und Ausgabe in einer (Web-)Anwendung ist eines der fundamentalen Prinzipien, um als Programmierer seine geistige Gesundheit zu behalten. Für die Ausgabe wird dabei eine zumeist einfache (Template-)Sprache verwendet, die verhindern soll, dass zu viel Logik in die Ausgabe wandert.
\nIn PHP wird dies in der Regel von Template-Engines wie Twig oder Smarty gelöst. Aber warum benötigen wir eigentlich eine Template-Engine? Könnte es sein, dass PHP ohne weitere Zusätze auch eine ganz passable Lösung für Templating parat hält?
", "content_encoded": "Die Trennung von Logik und Ausgabe in einer (Web-)Anwendung ist eines der fundamentalen Prinzipien, um als Programmierer seine geistige Gesundheit zu behalten. Für die Ausgabe wird dabei eine zumeist einfache (Template-)Sprache verwendet, die verhindern soll, dass zu viel Logik in die Ausgabe wandert.
\nIn PHP wird dies in der Regel von Template-Engines wie Twig oder Smarty gelöst. Aber warum benötigen wir eigentlich eine Template-Engine? Könnte es sein, dass PHP ohne weitere Zusätze auch eine ganz passable Lösung für Templating parat hält?
\n\nDie Hauptidee hinter den meisten Template-Engines ist:
\nif, while und for.Ein ausgezeichnetes Beispiel für die Philosophie von Template-Engines ist Mustache, das ein absolutes Minimum von Methoden anbietet, um Komplexität zu verhindern.
\nAber brauchen wir in PHP den Overhead einer Template-Engine wirklich? Oder können wir nicht mit ein bisschen Disziplin direkt mit PHP alle unsere Template-Bedürfnisse stillen – ohne uns in Abhängigkeit zu einer weiteren Software-Bibliothek zu begeben?
\nTatsächlich bietet PHP (auch aufgrund seiner Genese) sehr gute Möglichkeiten, Templating damit zu betreiben.
\nTemplate-Engines legen ihre Templates in der Regel in einen eigenen Ordner mit einer eigenen Dateiendung ab. In der Kombination Symfony mit Twig liegen Templates im Projekt in einem Ordner /templates und haben die Dateiendung .twig.
Tatsächlich hindert uns nichts daran, unsere PHP-Templates ebenfalls in einem /templates-Verzeichnis abzulegen. Als Datei-Endung verwenden wir dabei (analog zu Twig und zur Erhaltung der geistigen Gesundheit):
| Template-Ausgabe | \nDatei-Endung | \n(MIME-Type) | \n
|---|---|---|
| HTML-Dateien | \n*.html.php | \ntext/html | \n
| XML-Dateien | \n*.xml.php | \ntext/xml oder application/xml | \n
| JSON-Dateien | \n*.json.php | \napplication/json | \n
| Text-Dateien | \n*.txt.php | \ntext/plain | \n
| CSV-Dateien | \n*.csv.php | \ntext/csv | \n
Diese Liste lässt sich natürlich beliebig um neue Dateitypen erweitern. Wichtig ist nur, dass die Dateien auf PHP enden, damit sie einerseits von einem Code-Editor als PHP-Dateien erkannt werden, andererseits beim irrtümlichen Aufruf über einen Webserver auch als PHP ausgeführt werden, und nicht irgendwelche PHP-Geheimnisse verraten.
\nNach alter Sitte benennen wir das Template nach dem Controller. So wird das HTML-Template für den Index-Controller index.html.php, für den User-Controller user.html.php benannt. Das XML-Template für den Index-Controller ist dann entsprechend index.xml.php.
Templates, die keinen Controller zugeordnet werden können (sogenannte Snippets oder Partials) beginnen mit einem _, also zum Beispiel _meta.html.php. Was es mit diesen Dateien auf sich hat klären wir weiter unten.
Wir nutzen die Fähigkeit von PHP, dass jede Anweisung, die nicht in PHP-Tags (<?php ?>) steht, nicht als PHP verstanden wird, sondern direkt an den Browser zurückgegeben wird. Damit können wir innerhalb unserer Template-Dateien uns tatsächlich auf die Ausgabe konzentrieren:
<!DOCTYPE html>\n<html xmlns="http://www.w3.org/1999/xhtml" lang="en">\n<head>\n</head>\n<body>\n <!-- I am valid PHP -->\n</body>\nDie wichtigste Funktion eines Templates ist die Ausgabe von Variablen, die im Controller vorbereitet wurden. Dazu öffnen wir (wie in jeder Template-Sprache) einen Kommandoblock, und führen darin das Kommando zum Ausgeben von Variablen aus.
\n<!-- Bad idea -->\n<div><?php echo($title) ?></div>\nNetterweise gibt es eine PHP-Tag, das diese Ausgabe nochmals verkürzt:
\n<!-- Still a bad idea -->\n<div><?= $title ?></div>\nTatsächlich sind aber beide Wege eine ganz schlechte Idee, weil wir hier sträflich das Quoting / Escaping vernachlässigt haben – eine Kernfunktionalität einer jeden Template-Engine und ein Garant für die Sicherheit unserer Web-Applikation. Im obigen Beispiel wäre es möglich, dass in $title HTML steckt, was direkt wieder auf der Seite ausgegeben werden kann. In den wenigsten Fällen ist dies erwünscht und setzt voraus, dass man dem Variablen-Inhalt jederzeit vertrauen kann. Beispiel gefällig?
<!-- See, a bad idea -->\n<div><?= $_GET['search'] ?></div>\nPraktischerweise liefert PHP die Funktion htmlspecialchars mit, die einen String für die Ausgabe in sicherem HTML umwandelt. So werden Zeichen wie <, > und " sicher umgewandelt:
<!-- Better idea -->\n<div><?= htmlspecialchars($title) ?></div>\nDa diese Art der Ausgabe unsere Hauptmethode sein soll, die Schreibweise aber etwas sperrig ist, bauen wir uns einen Alias für htmlspecialchars. Der Beginn der kleinsten PHP-Template-Engine der Welt:
// Template.php\n\n/**\n * Alias for `htmlspecialchars`\n */\nfunction html($s): string\n{\n return htmlspecialchars($s);\n}\nDiese Funktion kürzt uns die Schreibarbeit ab, um eine Variable sicher auszugeben, und ist ab sofort unsere Hauptfunktion zur Ausgabe von Variablen:
\n<!-- Best idea -->\n<div><?= html($title) ?></div>\nPHP bietet aber noch mehr Funktion für Quoting / Escaping. Unter anderem müssen wir bei der Ausgabe von Query-Parametern in URLs Zeichen wie # und & umwandeln. Dafür hat PHP die Funktion urlencode parat – in Kombination mit unserer html-Funktion unschlagbar:
<a href="https://www.example.com?id=<?= html(urlencode($id)) ?>">Test</a>\nDann und wann müssen wir auch PHP-Variablen in JavaScript-Variablen umwandeln. Hier bietet sich die (etwas artfremde) Funktion json_encode an, die PHP-Variablen als JSON ausgibt. Damit wird die Variable nicht nur in korrekte Anführungszeichen gesetzt (die wir wiederum nicht HTML-enkodieren dürfen), sondern erlaubt sogar die Ausgabe von komplexen Variablen wie Arrays:
<script>\nvar data = <?= json_encode($data) ?>;\n</script>\nDie wichtigsten Kontrollstrukturen für das Templating sind Bedingungen. Hier ist das if der wichtigste Ansprechpartner. „Echtes“ PHP mit seinen geschweiften Klammern ist dabei aber eher unübersichtlich, da zum Beispiel bei Schachtelungen unklar sein kann, welche schließende Klammer für welchen Block zuständig ist:
<?php if (!empty($title)) { ?>\n <div><?= html($title) ?></div>\n<?php } ?>\nPraktischerweise kennt PHP auch eine alternative Syntax für Kontrollstrukturen, bei dem jeder Block hinter einem Kommando nicht mit einem {, sondern mit einem : beginnt – und statt mit einem } mit einem end...; beendet wird.
<?php if (!empty($title)): ?>\n <div><?= html($title) ?></div>\n<?php endif ?>\nIn den if-Bedingungen kann man dabei alle Operatoren und Funktionen verwenden, die PHP so kennt. Wichtig ist (wie immer), dass vor dem Verwenden einer Variable getestet wird, ob die Variable überhaupt definiert wird, was mit !empty oder isset geschehen kann.
Darüber hinaus stehen natürlich auch else und elseif zur Verfügung:
<?php if (!empty($results)): ?>\n <h4>Wir haben <?= html(count($results)) ?> Ergebnisse gefunden.</h4>\n<?php else: ?>\n <h4>Wir haben leider keine Ergebnisse gefunden.</h4>\n<?php endif ?>\nDie Ausgabe von Listen und Tabellen ist ebenfalls eine wichtige Funktion von Templates. Mittels Schleifen kann man zum Beispiel über vorher definierte Arrays iterieren – ebenfalls mit der alternative Syntax für Kontrollstrukturen:
\n<?php if (!empty($list)): ?>\n <ul>\n <?php foreach($list as $index => $item): ?>\n <li><?= html($item) ?></li>\n <?php endforeach ?>\n </ul>\n<?php endif ?>\nDabei funktionieren for, foreach und while ganz wunderbar:
<h4>Lottozahlen</h4>\n<ol>\n <?php for ($i = 1; $i <= 49; $i++): ?>\n <li>\n <input type="checkbox" name="lotto_<?= html($i) ?>" id="lotto_<?= html($i) ?>" value="1" />\n <label for="lotto_<?= html($i) ?>"><?= html($i) ?></label>\n </li>\n <?php endfor ?>\n</ol>\nUm Template-Teile wie zum Beispiel einen Header, Footer oder Navigation in ein Template einzufügen, fügen wir dem Dateinamen des Template-Teils einfach einen führenden _ hinzu, wie zum Beispiel _header.xml.php.
Ein Template-Teil (auch als Snippet oder Partial bekannt) kann mit dem PHP eigenen include ins ein anderes Template eingebunden werden:
<!DOCTYPE html>\n<html xmlns="http://www.w3.org/1999/xhtml" lang="en">\n<head>\n <?php include('_meta.html.php') ?>\n</head>\n<body>\n <?php include('_header.html.php') ?>\n ...\n <?php include('_footer_.html.php') ?>\n</body>\nSogar Übersetzungen von Templates beherrscht PHP! Die in PHP vorhandene Gettext-Bibliothek erlaubt es, einen String zu übergeben, für den Gettext in einem beigefügten Wörterbuch nach der korrekten Übersetzung sucht, und diesen zurückgibt.
\nWichtig dafür ist das Setzen der Locale in PHP mittels setlocale:
setlocale(LC_MESSAGES, 'de_DE');\nDie korrekte Bedienung dieser Funktion sorgt übrigens auch für die Übersetzung von Zahlen- und Datumsformaten, wie auch Datumsbezeichnern.
\nDie eigentlich zu übersetzenden Bezeichner können an die Funktion gettext bzw. _ übergeben werden.
<!-- translate to 'Guten Morgen!' -->\n<h4><?= html(_('Good morning!')) ?></h4>\nDie dafür notwendigen Wörterbücher kann man spielend leicht selber erstellen. Die dafür notwendigen PO- und MO-Dateien kann man zum Beispiel mit Poedit erstellen. Poedit ist sogar in der Lage, die gesamte PHP-Programmierung nach noch nicht katalogisierten, übersetzbaren Strings zu durchsuchen.
\nWenn wir mit Variablen-Ersetzung arbeiten, wird die Konstruktion etwas schwieriger:
\n<div><?= html(vsprintf(_('There are %d results'), [$count])) ?></div>\nDa wir so ziemlich jeden hardcodierten Text übersetzbar machen wollen, können wir unserer simplen Template-Engine eine weitere Funktion als Abkürzung hinzufügen:
\n// Template.php\n\n/**\n * Alias for `vsprintf`, but with HTML escaping and translation\n */\nfunction _html(string $format, array $args = []): string\n{\n return htmlspecialchars($args\n ? vsprintf(_($format), $args)\n : _($format)\n );\n}\n…was den Aufruf deutlich einfacher macht:
\n<h4><?= _html('Good morning!') ?></h4>\n<div><?= _html('There are %d results', [$count]) ?></div>\nFür Entwickler wie auch Template-Designer ist es hilfreich, sich komplexe Variablen im Frontend zu Debugging-Zwecken ausgeben zu lassen. Dafür bietet PHP die Funktionen print_r und var_dump / var_export. Dummerweise ist in HTML ein solcher Dump schwer lesbar, da die Zeilenumbrüche in HTML ignoriert werden. Eine kleine Funktion für unsere Template-Engine kann auch diesen Missstand beheben:
// Template.php\n\n/**\n * HTML dumper für PHP variables\n */\nfunction debug($mixed, bool $extended = false): void\n{\n echo('<pre class="debug" style="margin: 1em 0; border: 1px solid red; background: #fee; color: #000; padding: 1em;">');\n echo(htmlspecialchars($extended\n ? var_export($mixed, true)\n : print_r($mixed, true)\n ));\n echo('</pre>');\n}\nDamit können auch komplexe Variablen bis hin zu Objekten lesbar ausgegeben werden:
\n<?php debug($data) ?>\nStatt einer weithin sichtbaren Debug-Ausgabe könnte man natürlich gleich auf die Ausgabe von Debugging-Daten in der Browser-Console ausweichen.
\nPHP erzeugt von Haus aus eine HTML-Ausgabe. Im Browser funktioniert dies so, dass jedes PHP-Skript den Webserver anweist, als MIME-Type text/html zurückzugeben. Tatsächlich kann PHP aber auch ganz andere MIME-Types ausgeben. Dazu gibt es die Funktion header, mit der PHP den Webserver anweisen kann, bestehende Header zu ändern bzw. neue zu setzen. Der für uns interessante Header ist Content-Type.
So können wir PHP anweisen, jeden erdenklichen MIME-Type zurückzugeben.
\nFür XML verwenden wir die Template-Endung .xml.php, also zum Beispiel sitemap.xml.php. Diese Templates unterscheiden sich tatsächlich nicht großartig von HTML-Templates, und verwenden sogar die selben Quoting/Escaping-Funktionen. Nur der zusätzliche Content-Type-Header muss mitgeschickt werden:
<?php header('Content-Type: text/xml'); ?>\n<urlset>\n <?php foreach($urls as $url): ?>\n <url>\n <loc><?= html($url) ?></loc>\n </url>\n <?php endforeach ?>\n</urlset>\nAuch JSON kann PHP für uns ausgeben. Hierfür verwenden wir die Template-Endung .json.php, wie zum Beispiel feed.json.php, und senden wieder den korrekten Content-Type. Um das Quoting/Escaping in den Griff zu bekommen, bauen wir unser JSON nicht von Hand, sondern verwenden die Funktion json_encode, die auch strukturierte PHP-Variablen strukturiert und proper formatiert ausspuckt:
<?php\n header('Content-Type: application/json');\n echo(json_encode($data));\nFür besonders schönes JSON kann man übrigens den Parameter JSON_PRETTY_PRINT mitgeben:
<?php\n header('Content-Type: application/json');\n echo(json_encode($data, JSON_PRETTY_PRINT));\nÜbrigens respektiert die Funktion json_encode tatsächlich PHP-Typen. Damit werden PHP-Integer tatsächlich als JSON-Integer ausgegeben, und PHP-Strings als JSON-Strings. Hier muss also in PHP den Unterschied zwischen 1 und „1“ berücksichtigt werden.
Die obigen Beispiele zum Setzen des korrekten MIME-Types und Holen der Templates kann man natürlich auch allgemein lösen:
\n// e.g. $template = 'index';\n// e.g. $contentType = 'html';\n\nswitch ($contentType) {\n case 'xml':\n header('Content-Type: text/xml');\n break;\n case 'json':\n header('Content-Type: application/json');\n break;\n case 'txt':\n header('Content-Type: text/plain');\n break;\n case 'csv':\n header('Content-Type: text/csv');\n break;\n default:\n $contentType = 'html';\n break;\n}\n\n$templateFilename = __DIR__ . '/templates/' . $template . '.' . $contentType . '.php';\nrequire($templateFilename);\nJedes PHP-Projekt braucht eine saubere Trennung zwischen Logik und Ausgabe – aber für diese Trennung braucht es nicht immer eine Template-Engine wie Twig oder Smarty. Auch handelsübliches PHP kann (mit wenigen, kleinen Helferlein) eine performante, wartungsarme Alternative fürs Templating sein.
\nHier nochmals eine Übersicht über die wichtigsten PHP-Funktionen für Templating:
\n| Funktion | \nAlias | \nBeschreibung | \n
|---|---|---|
htmlspecialchars | \nhtml | \nHTML-Escaping | \n
urlencode | \n- | \nURL-Escaping | \n
json_encode | \n- | \nJSON/JavaScript-Escaping | \n
setlocale | \n- | \nSetzen der Sprache für Übersetzungen | \n
gettext / _ | \n_html | \nAusgabe von Übersetzungen | \n
strftime | \n- | \nGibt ein lokales Datumsformat aus | \n
localeconv | \n- | \nErmittelt die lokale Ausgabeeinstellungen für Zahlen | \n
printf | \n_html | \nAusgabe von Variablen in Strings | \n
nl2br | \n- | \nKonvertiert Zeilenumbrüche in HTML-<br /> | \n
implode | \n- | \nVerbindet ein Array zu einem String | \n
var_dump | \ndebug | \nDump von PHP-Variablen | \n
header | \n- | \nAusgabe von anderen Content-Type | \n
Einzig beim Thema Vererbung von Templates sind echte Template-Engines deutlich komfortabler, wie Twigs Template-Vererbung und Smartys Template-Vererbung zeigen. Siehe dazu auch den Vergleich der Templating-Engines für PHP auf CSS-Tricks.
\nThere also is an English version of this article, „World's smallest template engine“.
Wie schon in dem Artikel „Simple & Boring“ von Chris Coyier hat auch Bastian Allgeier eine Lanze für Einfachheit in der Programmierung gebrochen. Sein Artikel „Simplicity (II)“ dürfte vielen altgedienten Programmierern aus der Seele sprechen.
\nTatsächlich bemerke ich sowohl in der privaten als auch beruflichen Programmierung den Trend, für mehr Geschwindigkeit ein neues Tool einzusetzen… das kleine Probleme verursacht, die durch ein weiteres Tool gelöst werden müssen… das kleine Probleme verursacht, die durch ein weiteres Tool gelöst werden müssen…
\n\nWhen everything works, it feels like magic. When something breaks, it's hell.
Der Artikel dreht sich zwar primär darum, was diese Abhängigkeiten gerade für ältere Projekte bedeuten (nämlich, dass Abhängigkeiten nach ein paar Jahren sich nicht wieder auslösen lassen, weil die dafür benötigten Versionen an Tools nicht mehr zur Verfügung stehen), inzwischen bemerke ich aber auch bei aktuellen Projekten die Probleme, die übermäßige Abhängigkeiten für die Entwicklungsgeschwindigkeit bedeuten können, wenn auch nur ein Teil ausfällt.
", "content_encoded": "Wie schon in dem Artikel „Simple & Boring“ von Chris Coyier hat auch Bastian Allgeier eine Lanze für Einfachheit in der Programmierung gebrochen. Sein Artikel „Simplicity (II)“ dürfte vielen altgedienten Programmierern aus der Seele sprechen.
\nTatsächlich bemerke ich sowohl in der privaten als auch beruflichen Programmierung den Trend, für mehr Geschwindigkeit ein neues Tool einzusetzen… das kleine Probleme verursacht, die durch ein weiteres Tool gelöst werden müssen… das kleine Probleme verursacht, die durch ein weiteres Tool gelöst werden müssen…
\n\nWhen everything works, it feels like magic. When something breaks, it's hell.
Der Artikel dreht sich zwar primär darum, was diese Abhängigkeiten gerade für ältere Projekte bedeuten (nämlich, dass Abhängigkeiten nach ein paar Jahren sich nicht wieder auslösen lassen, weil die dafür benötigten Versionen an Tools nicht mehr zur Verfügung stehen), inzwischen bemerke ich aber auch bei aktuellen Projekten die Probleme, die übermäßige Abhängigkeiten für die Entwicklungsgeschwindigkeit bedeuten können, wenn auch nur ein Teil ausfällt.
Immer wieder haben wir in der Programmierung die Herausforderung, strukturierte Daten von Nutzern eingeben zu lassen. Ein wunderbares Format dafür ist YAML.
", "content_encoded": "Immer wieder haben wir in der Programmierung die Herausforderung, strukturierte Daten von Nutzern eingeben zu lassen. Ein wunderbares Format dafür ist YAML.
\n\nYAML hat den Vorteil, dass es auch von unversierten Nutzern eingegeben werden kann – ein Vorteil gegenüber XML oder JSON, und auch INI ist nicht unbedingt das einfachste Format, wenn es um eine entspannte Leerzeichenhandhabung geht.
\nSo ist die Eingabe und auch Speicherung von YAML eigentlich trivial. Eine <textarea /> im Browser, ein Textfeld in der Datenbank, und ein YAML-Parser zum Umwandeln der Daten in benutzbare Variablen – fertig ist die Konfigurationsmöglichkeit.
YAML-Parser gibt es eigentlich für so ziemlich jede Sprache, wenn auch zumeist nicht als integralen Bestandteil. So muss man z.B. bei PHP weitere Bibliotheken installieren.
\nFür Konfigurationen reicht zumeist ein einfache Untermenge von YAML aus: Eine Sammlung von key: value-Zuordnungen, sogenannte Block Mappings. Diese erlauben tabellarische Zuordnung von strukturierten, schemalosen Daten. Für meinen Fall gibt es eine weitere Einschränkung: Die Werte dürfen nur einzeilig sein:
en_GB: https://www.example.co.uk/\nfr_FR: https://www.example.fr/\nde_DE: https://www.example.de/\nUm den Aufwand für einen echten YAML-Parser zu vermeiden, habe ich mir für exakt diesen sehr einfachen Anwendungsfall einen maximal-einfachen Parser gebaut, der Block Mappings konvertiert.
\nDer Konverter erzeugt ein strukturiertes, assoziatives Array:
\n/**\n * Convert lines like `a: b` into an associative array like `['a' => 'b']`.\n * @param string $string\n * @return array \n */\nfunction parseSimpleYaml(string $yamlString): array\n{\n return preg_match_all('/(?:^|\\n)\\s*([^#].+?)\\s*:\\s*([^\\n#]+)/', trim($yamlString), $matches)\n ? array_combine($matches[1], $matches[2])\n : [$yamlString]\n ;\n}\nDamit wird aus dem o.a. YAML Block Mapping ein assoziatives Array:
\n[\n 'en_GB' => 'https://www.example.co.uk/',\n 'fr_FR' => 'https://www.example.fr/',\n 'de_DE' => 'https://www.example.de/',\n]\nEine ähnliche Methode kann man in JavaScript anwenden:
\nconst parseSimpleYaml = function(yamlString) {\n let yamlObject = {};\n yamlString\n .split("\\n")\n .map((i) => {\n return i.match(/^([^#].+?)\\s*:\\s*([^\\n#]+)/);\n })\n .filter((i) => {\n return i !== null\n })\n .forEach((i) => {\n yamlObject[i[1]] = i[2];\n })\n ;\n return yamlObject;\n}\nDamit wird aus dem o.a. YAML Block Mapping ein assoziatives Objekt:
\n{\n 'en_GB': 'https://www.example.co.uk/',\n 'fr_FR': 'https://www.example.fr/',\n 'de_DE': 'https://www.example.de/',\n}\nEhrlich gesagt könnte man für o.a. einfaches Speicherformat auch ein vereinfachtes INI-Format verwenden:
\nen_GB=https://www.example.co.uk/\nfr_FR=https://www.example.fr/\nde_DE=https://www.example.de/\nStrukturell funktioniert das exakt gleich, nur dass der zum Auslesen verwendete reguläre Ausdruck nun wie folgt aussieht:/(?:^|\\n)\\s*([^;].+?)\\s*=\\s*([^\\n;]+)/
Mein Kollege Slawo hat mich schon vor geraumer Zeit auf einen interessanten Code-Editor hingewiesen: Microsofts Visual Studio Code (oder kurz „VS Code“). Microsofts Charme-Offensive in Richtung der Developer-Community hat ein ganz neues Werkzeug hervorgebracht, dass es mit den etablierten Konkurrenten vom Range eines Sublime Text, Atom und Co aufnehmen soll.
", "content_encoded": "
Mein Kollege Slawo hat mich schon vor geraumer Zeit auf einen interessanten Code-Editor hingewiesen: Microsofts Visual Studio Code (oder kurz „VS Code“). Microsofts Charme-Offensive in Richtung der Developer-Community hat ein ganz neues Werkzeug hervorgebracht, dass es mit den etablierten Konkurrenten vom Range eines Sublime Text, Atom und Co aufnehmen soll.
\n\nLange Jahre war Sublime Text 2 bzw. 3 mein Lieblings-Code-Editor. Vor allen Dingen die hohe Geschwindigkeit beim Tippen als auch die unglaublich schnelle Suche machten für mich lange Jahre die Benutzung einer echten IDE überflüssig. Mit Hilfe von unzähligen Sublime-Plugins habe ich mich da inzwischen sehr gemütlich eingerichtet.
\nBeruflich bin ich aber inzwischen bei PhpStorm angelangt, und habe mich da an bestimmten Luxus gewöhnt. Hervorragendes Auto-Complete bzw. die Verlinkung von Objekten im Quellcode, die direkte Anzeige von Fehlern oder die Integration von SQL, Git und Terminals vermisste man dann und wann doch in Sublime Text. Dafür war mir bei PhpStorm schon immer seine Behäbigkeit und sein Ressourcenhunger für das heimische Arbeiten ein Gräuel.
\nWonach ich also suchte ist die Spritzigkeit von Sublime Text 3, und die integrierte Arbeitsweise und Unterstützung von PhpStorm. Für mich selber habe ich mit Microsoft Visual Studio Code den perfekten Kompromiss gefunden – zumal dieser Kompromiss keinen Cent kostet.
\n\nSublime Text 3 ist der schnellste Klappspaten unter den Editoren, während PhpStorm das Äquivalent eines Braunkohletagebaubaggers ist.
Damit entspricht Microsofts Visual Studio Code einem Bobcat-Bagger.
Meine Highlights bei VS Code:
\nPersönlich wechsele ich ungern meine Werkzeuge aus, wenn ich nicht einen echten Grund dafür verspüre. Ich werfe gerne ein Auge auf die Trends in diesem Bereich, ohne andauernd den Drang zu verspüren, alles selber ausprobieren zu müssen. Außerdem möchte ich eigentlich wenig Zeit mit meinen Werkzeugen, sondern lieber mit meiner Arbeit verbringen. Umso größer ist für mich also der Schritt, meinen Code-Editor auszutauschen – das zentrale Werkzeug, dass meine Ideen in ausführbaren Code verwandelt.
\nWie bei jedem Editor-Wechsel war am Anfang etwas Fremdeln angesagt. Chris Coyiers Artikel über den Umstieg auf VS Code hat mir zum Glück gerade noch rechtzeitig die Möglichkeit erläutert, mit einem Plugin das Verhalten von VS Code in einigen relevanten Bereichen (z.B. Tastaturkürzel) einfach auf das Verhalten von Sublime Text 3 abzuändern.
\nVS Code nutze ich daheim aktuell für folgende Projekt-Typen:
\nÜberraschenderweise ist VS Code für Windows, Mac OSX und Linux verfügbar.
\nDirekt nach der Installation stellt man überrascht fest, dass es eigentlich nicht viele Plugins braucht; VS Code hat unglaublich viele Funktionalitäten von vorne herein integriert. So ist für die Verwendung von Gulp, Grunt, Sass, ESlint, Php-Debuggern und vielen anderen Notwendigkeiten des Webentwickler-Lebens bereits Vorsorge getroffen. Selbst eine Live-Preview von Markdown, ein Terminal und Git ist integriert. Daher ist meine persönliche Liste von zusätzlichen Plugins relativ bescheiden:
\n/** automatisch für den dahinter liegenden Code-Abschnitt einen PhpDoc-Kommentar erzeugen lassen.Für viele verschiedene Programmieraufgaben stellt Microsoft Tutorials für VS Code bereit. Die Palette der im Standard unterstützten Sprachen von VS Code reicht dabei von HTML, CSS, JavaScript und PHP über Node.js hin zu C#, C/C++, ohne das diese Liste erschöpfend alle unterstützten Sprachen enthält.
\nIn Kombination mit der Erweiterbarkeit und der Möglichkeit, Kommandozeilentools in VS Code einzubinden, steht dem geneigten Entwickler so ziemlich jede Sprache bequem zur Verfügung.
\nÜbrigens sieht Visual Studio Live Share sehr spannend aus: Hier können mehrere Programmierer zusammen in Echtzeit ein und dieselbe Datei bearbeiten. Das habe ich persönlich zwar noch nicht ausprobiert, Youtube-Videos davon sehen aber sehr interessant aus:
\n\nMeine persönlichen Einstellungen in der settings.json…
{\n "editor.fontSize": 13,\n "editor.formatOnPaste": false,\n "editor.formatOnSave": false,\n "editor.largeFileOptimizations": false,\n "editor.multiCursorModifier": "ctrlCmd",\n "editor.renderWhitespace": "boundary",\n "editor.rulers": [80, 120],\n "editor.snippetSuggestions": "top",\n "editor.tabSize": 2,\n "editor.useTabStops": false,\n "editor.wordWrap": "on",\n "explorer.confirmDelete": false,\n "files.autoSave": "onFocusChange",\n "files.eol": "\\n",\n "files.exclude": {\n ".idea": true,\n ".vscode": true\n },\n "git.autofetch": true,\n "git.enableSmartCommit": true,\n "git.path": "C:\\\\Program Files\\\\Git\\\\bin\\\\git.exe",\n "npm.enableScriptExplorer": true,\n "spellright.documentTypes": [\n "markdown",\n "latex",\n "plaintext"\n ],\n "terminal.integrated.shell.windows": "C:\\\\Program Files\\\\Git\\\\bin\\\\bash.exe",\n "workbench.colorTheme": "Monokai",\n "php.validate.executablePath": "C:\\\\xampp\\\\php\\\\php.exe",\n "editor.defaultFormatter": "esbenp.prettier-vscode"\n}\n…und der keybindings.json…
[\n { "key": "ctrl+g", "command": "editor.action.nextMatchFindAction" },\n { "key": "ctrl+7", "command": "editor.action.commentLine", "when": "editorTextFocus && !editorReadonly" },\n { "key": "ctrl+shift+7", "command": "editor.action.blockComment", "when": "editorFocus" },\n { "key": "ctrl+shift+d", "command": "editor.action.copyLinesDownAction", "when": "editorFocus" },\n { "key": "ctrl+d", "command": "editor.action.addSelectionToNextFindMatch", "when": "editorFocus" },\n { "key": "ctrl+h", "command": "editor.action.startFindReplaceAction" },\n { "key": "ctrl+shift+up", "command": "editor.action.moveLinesUpAction" },\n { "key": "ctrl+shift+down", "command": "editor.action.moveLinesDownAction" }\n]\n…sind direkte Übernahmen des Verhaltens, dass ich mir schon für Sublime Text 3 überlegt hatte. Viel mehr Konfiguration ist dann nicht mehr nötig.
\nBei meinen ersten Versuchen scheiterte ich daran, den in VS Code integrierten Git-Client zum Laufen zu bringen. Obwohl auf der Kommandozeile und auch in einem lokal installierten Source Tree alles ganz wunderbar lief, wehrte sich VS Code gegen git push und git pull mit dem Hinweis, dass der Git-Server meine Credentials nicht mochte. Die Lösung dafür war aber gar nicht so komplex:
Die Voraussetzungen für die Benutzung von Git direkt aus Microsofts Visual Studio Code ist die Installation von Git Credential Manager (bei neuerem Git wird dies automatisch mit dabei sein) und Plink von Putty, dass den SSH-Schlüssel für Git bereitstellt.
\nAußerdem sollte eine globale Systemvariable vorhanden sein, die auf plink.exe verweist. Das kann man mit der Windows Eingabeaufforderung erledigen:
set GIT_SSH="C:\\Program Files\\PuTTY\\plink.exe"\nsetx GIT_SSH %GIT_SSH%\necho %GIT_SSH%\nSobald der SSH-Schlüssel in Pageant geladen ist, kann VS Code auch problemlos alle Git-Kommandos ausführen.
\nFür meine heimische Arbeit ist Microsofts Visual Studio Code der würdige Nachfolger von Sublime Text 3. Er ist nicht nur kostenlos, sondern lässt mich (fast) so schnell wie mit Sublime Text 3 arbeiten, während er gleichzeitig viele Annehmlichkeiten einer echten IDE mitbringt.
Schon vor längerer Zeit hatte ich mir darüber Gedanken gemacht, wie man PHP-Klassen in Javascript-Objekte übersetzt. Jetzt habe ich einen kleinen Helfer bauen können, der einen Großteil der Arbeit automatisiert.
", "content_encoded": "Schon vor längerer Zeit hatte ich mir darüber Gedanken gemacht, wie man PHP-Klassen in Javascript-Objekte übersetzt. Jetzt habe ich einen kleinen Helfer bauen können, der einen Großteil der Arbeit automatisiert.
\n\nWie man am Beispiel eines kleinen Vigenère-Listings sieht, sind die Strukturen von PHP-Klassen und Javascript-Objekten eigentlich sehr gleichartig. Mit der folgenden Javascript kann man einen Großteil der Transformation durchführen, und muss danach nur noch einige Details anpassen.
\n/**\n * Afterwards you will need to:\n * - add `var` in front of uninitialized variables\n * - move default values for function parameters into function body like `param = param || 'default';`\n * - add `,` after every object property (variables & methods)\n * - replace PHP functions\n * @param {String} php [description]\n * @return {String} [description]\n */\nvar transformPhpToJs = function(php) {\n return php\n .replace(/<\\?php\\s*/g, '')\n .replace(/\\?>\\s*/g, '')\n .replace(/(protected|public|private|const) (\\S+)\\s?=/g, '$2 :')\n .replace(/(protected|public|private|const) /g, '')\n .replace(/(function) (\\S+)\\s?/g, '$2: $1')\n .replace(/(class) (\\S+)\\s?/g, 'var $2 = ')\n .replace(/\\$/g, '')\n .replace(/SELF::/g, 'this.')\n .replace(/->/g, '.')\n .replace(/array\\(([\\s\\S]*?)\\);/g, '[$1];')\n .replace(/=>/g, ':')\n .replace(/empty\\((.+?)\\)/g, '!$1')\n .replace(/preg_replace\\(['"](.+?)['"],(.+?),\\s?(.+?)\\s?\\)/g, '$3.replace(/$1/g,$2)')\n .replace(/preg_match\\(['"](.+?)['"],\\s?(.+?)\\s?\\)/g, '$2.match(/$1/)')\n ;\n}\nDiese Funktion könnt ihr z.B. in die F12-Konsole von eurem Browser eingeben, und danach euren PHP-Quelltext im Browser übersetzen lassen. Folgender Aufruf gibt euch das transformierte PHP zurück:
transformPhpToJs(`INSERT YOUR PHP HERE`);\nGeht dafür wie folgt vor:
\nF12 eure Entwicklerkonsole.Enter.Natürlich muss das Ergebnis noch nachbearbeitet werden, aber für die meisten Fälle erledigt es zumindest die groben Arbeiten. Danach könnt ihr z.B. daran gehen die richtige NodeJS-Modul-Struktur einzubauen.
\nUpdate: Mathias hat mich auf Locutus aufmerksam gemacht:
\n\nLocutus is a project that seeks to assimilate other languages’ standard libraries to JavaScript.
Hier findet ihr viele PHP-Funktionen als Javascript-Module umgesetzt. Die ganze Bibliothek ist zwar mit Augenzwinkern zu verstehen, für schnelle Erfolgserlebnisse eignet sie sich aber alle Mal.
Mittels eines kleinen Dreizeilers und der Hilfe von OpenStreetMap kann man mit PHP Adressen in WGS84-Geokoordinaten verwandeln:
\n/**\n * Convert address into WGS84 geo coordinates.\n * @see http://wiki.openstreetmap.org/wiki/Nominatim\n * @param string $address\n * @return array with lat / lon\n */\nfunction getCoordinates(string $address): array\n{\n $url = 'https://nominatim.openstreetmap.org/search?q=' . urlencode($address) . '&format=json&limit=1';\n $json = json_decode(file_get_contents($url), true);\n\n return (!empty($json[0])) ? $json[0] : ['lat' => null, 'lon' => null];\n}\nDiese Lösung ignoriert natürlich ein paar Komplikationen, die beim Anfragen der Schnittstelle auftreten können. Für eine einfache Anfrage mit geringer Frequenz und ggf. auch längerer Antwortzeit liefert die o.a. Funktion ein ganz passables Ergebnis.
", "content_encoded": "Mittels eines kleinen Dreizeilers und der Hilfe von OpenStreetMap kann man mit PHP Adressen in WGS84-Geokoordinaten verwandeln:
\n/**\n * Convert address into WGS84 geo coordinates.\n * @see http://wiki.openstreetmap.org/wiki/Nominatim\n * @param string $address\n * @return array with lat / lon\n */\nfunction getCoordinates(string $address): array\n{\n $url = 'https://nominatim.openstreetmap.org/search?q=' . urlencode($address) . '&format=json&limit=1';\n $json = json_decode(file_get_contents($url), true);\n\n return (!empty($json[0])) ? $json[0] : ['lat' => null, 'lon' => null];\n}\nDiese Lösung ignoriert natürlich ein paar Komplikationen, die beim Anfragen der Schnittstelle auftreten können. Für eine einfache Anfrage mit geringer Frequenz und ggf. auch längerer Antwortzeit liefert die o.a. Funktion ein ganz passables Ergebnis.
\n\nNach einem Refactoring mit cURL sieht das bereits deutlich komplexer aus, kann aber auch auf deutlich mehr Fehlerfälle reagieren und bricht bei Timeouts auch ab:
\nfunction getCoordinates(string $address): array\n{\n $url = 'https://nominatim.openstreetmap.org/search?q=' . urlencode($address) . '&format=json&limit=1';\n $ch = curl_init();\n curl_setopt($ch, CURLOPT_URL, $url);\n curl_setopt($ch, CURLOPT_HEADER, 0);\n curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);\n curl_setopt($ch, CURLOPT_TIMEOUT, 3);\n curl_setopt($ch, CURLOPT_USERAGENT, 'Some PHP Function');\n curl_setopt($ch, CURLOPT_HTTPHEADER, ['Accept: application/json']);\n $response = curl_exec($ch);\n $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);\n curl_close($ch);\n\n if ($httpCode < 300 && $response) {\n $json = json_decode($response, true);\n if ($json[0]) {\n return $json[0];\n }\n }\n\n return ['lat' => null, 'lon' => null];\n}\nDie API ist aber nicht für den Einsatz für Bulk-Adressumwandlung geeignet – wie auch die Nutzungsbedingung der API erläutern.
Die fantastische Javascript-console kann ganz wunderbar strukturierte Javascript-Informationen ausgeben. Mit einem relativ einfachen Trick kann sie auch strukturierte PHP-Daten (wie z.B. Arrays und Objekte) ausgeben.
Die fantastische Javascript-console kann ganz wunderbar strukturierte Javascript-Informationen ausgeben. Mit einem relativ einfachen Trick kann sie auch strukturierte PHP-Daten (wie z.B. Arrays und Objekte) ausgeben.
Folgende PHP-Funktion kürzt diesen Prozess deutlich ab:
\n/**\n * Debug PHP variable to browser console\n * @param mixed $mixed [description]\n */\nfunction console_log($mixed)\n{\n echo('<script>console.log(' . json_encode($mixed) . ');</script>');\n}\nDie Funktion erzeugt einfach das notwendige HTML, um den Inhalt des Parameters an die Console eines Browsers zu übergeben. Die strukturierten Daten sieht man dann beim nächsten Neuladen der betreffenden Seite. (Die Console öffnet man bei den meisten Browsern übrigens via F12 bzw. Ctrl+Shift+C.)
In PhpStorm kann man auch ein Live-Template definieren, und dann mittels Ctrl+J / Ctrl+Alt+T aufrufen:
echo('<script>console.log(' . json_encode($SELECTION$) . ');</script>');\nSo erzeugt der folgende Code…
\n$coords = Coordinates::set(40.7143528, -74.0059731, 10, 'New York City');\n$coords2 = $coords->getRelativeCoordinates(1000, 45);\necho('<script>console.log(' . json_encode($coords2) . ');</script>');\n…die folgende Ausgabe im Browser:
\n![\"Eine](\"https://journal.3960.org/posts/einfachste-php-objekt-debugger-fuer-browser/php-console.png\")
Autoloading ist in PHP eine feine Sache. Statt jede einzelne Klasse mittels eigenem require einzubinden, kann man bei existierendem Autoloader einfach durch Aufruf der Klasse diese laden.
Autoloading ist in PHP eine feine Sache. Statt jede einzelne Klasse mittels eigenem require einzubinden, kann man bei existierendem Autoloader einfach durch Aufruf der Klasse diese laden.
Eine Klasse legt man dabei einfach in einer Verzeichnisstruktur ab, z.B. unter Example/Foo/Bar.php:
// Example/Foo/Bar.php\n\nnamespace Example\\Foo;\n\nclass Bar {\n // Stuff here\n}\nDer kleinste Autoloader der Welt mit autoload_register verarbeitet dann alle in PHP ansonsten unbekannten Klassen:
spl_autoload_register(function(string $classname) {\n require(__DIR__ . '/' . str_replace('\\\\', '/', $classname) . '.php');\n});\nDabei muss der vordere Part mit __DIR__ . ‚/‘ natürlich auf den richtigen Basispfad gesetzt werden, in dem dann die Klassen liegen.
Und die Klasse setzt man dann nach eingeschalteten Autoloader wie folgt ein:
\n// See, no require here\n\n$bar = new \\Example\\Foo\\Bar();\nDen kleinsten PHP-Autoloader der Welt kann man auch gut mit anderen Autoloadern zusammen verwenden, wie z.B. dem Composer-Autoloader.
\nUpdate 2022–10: Seit PHP8 spätestens ist die Verwendung von __autload nicht mehr möglich, daher benutzt das Beispiel nur noch autoload_register.