Der Plan war einfach: Ich wollte eine kleine, XML-basierte Adressverwaltung, die ich für die Seite meines Aikido-Vereins entwickelt hatte, für andere Adressen verwenden. Die Verwaltung besteht aus ein paar PHP-Skripten, und es sollte eigentlich kein Problem darstellen, die Skripte von einem Webspace auf einen anderen zu kopieren und dort dann gleich – testmäßig – zum Laufen zu bringen. Durch meinen weitsichtigen Einsatz von PHP war das jedoch nicht möglich.
Der erste Aufruf des Haupt-Skripts führte zu einer leeren Seite, ohne Inhalt. Unter Einsatz der fortschrittlichsten Debugging-Techniken (fDT), die mir unter PHP zur Verfügung stehen fand ich dann heraus, dass es an der Zeile
if(!$dom = domxml_open_mem($showfile)) {hängen muss. Seltsam, weil der Dateiname, der in $showfile angegeben ist, eine bestehende Datei bezeichnet. Und, wie gesagt, ich habe erstmal alles kopiert, nicht nur die Skripte, sondern auch die Daten-Dateien und Verzeichnisse. Auf dem einen Webspace funktionierte es, auf dem anderen nicht.
Achso, bei der oben angesprochenen fDT handelt es sich übrigens um die Codezeile echo "hier";, unter Umständen ist der ausgegebene String komplizierter, aber im Prinzip sind das erstmal die Debugging-Möglichkeiten, die PHP bietet. (Einen kleinen Überblick über die wenigen darüberhinausgehenden Techniken finden sich unter DebuggingPHP.) Das echo in einer Zeile nach der oben auszugsweise dargestellten if-Anweisung wird nicht mehr erreicht. Also liegt’s am Inhalt der if-Anweisung. Zumindest sollte es das. Logik, die man in 6 Jahren Studium lernt…
Nachdem die Datei $showfile existiert, ist das domxml_open_mem der nächste Verdächtige. Und es stellt sich heraus, dass das Skript tatsächlich beim Abarbeiten dieser Funktion aussteigt. Warum auch immer.
Tja, um dieses Warum tiefer zu ergründen, ist ein Eintrag in der php.ini besonders hilfreich. Beim Entwickeln von PHP-Skripten (was hoffentlich nicht mehr allzu oft vorkommen wird), werde ich diese Option in Zukunft immer aktivieren:
display_errors = OnNach dem Entwickeln aber nicht vergessen, die Option wieder auf Off zu stellen. Die Besucher einer Seite brauchen ja nicht zu wissen, was alles nicht funktioniert. 
Das Aktivieren dieser Option mit anschließendem Neuladen der Seite führt zu der Meldung, dass domxml_open_mem eine unbekannte Funktion sei. Moment! PHP != PHP?
Ok, es könnte sein, dass einige Module, darunter das hier wohl benötigte XML-DOM-Modul, nicht geladen sind. Ein
<?php
phpinfo();
?>ergibt aber anderes. Das XML-DOM-Modul ist geladen. Vielleicht ein anderes? Wo ist denn domxml_open_mem normalerweise definiert? Was ist denn PECL? Ok, ich muss also wohl eine Erweiterung aktivieren. Reicht nicht, weil nicht vorhanden, also Download und Installation. Will ich nicht… (Ich kürze hier ein wenig den Findungsprozess ab.)
Die Suche nach einer Alternative
Der Aufruf von phpinfo() ergab, dass ich auf dem neuen Webserver auch eine neuere PHP-Version (5, statt 4) zur Verfügung habe. Vielleicht gibt’s da einen guten Ersatz, so dass ich dieses PECL-Dingens nicht installieren muss. Gibt es. Einiges. SimpleXML reicht aber nicht, weil ich XML auch erzeugen können muss.
Ahh, DOM hilft weiter. Wer hätte das gedacht.
Lange Rede
Nach einigem Suchen und Experimentieren habe ich herausgefunden, dass in PHP 5 die von mir verwendeten und in PHP 4 vorhandenen XML-DOM-Funktionen nicht mehr vorhanden sind. Sie wurden durch andere Funktionen ersetzt. Ich finde die neue Nomenklatur im Vergleich zur alten total spannend, und möchte sie dem ausharrenden Leser nicht vorenthalten. Einige Beispiele:
| alt | neu | Bedeutung |
|---|---|---|
| DomDocument | DOMDocument | Root-Element eines XML-Dokuments |
| create_node() | createNode() | erzeugt neuen XML-Knoten |
| node_name() | nodeName | gibt den Namen eines Knotens (den Elementnamen) zurück |
Diese kleine Tabelle gibt im Groben wieder, was sich zwischen PHP 4 und 5 in Sachen XML geändert hat. Zumindest was mich betrifft.
Man kann zwei Sachen schnell erkennen:
- Bei der Benamung der verschiedenen Elemente wurde in der alten Version offensichtlich soviel Hirnschmalz verbraten, dass sie in der neuen Version abgeändert wurde. Gut zu wissen, dass es – auch aus designtechnischen Gründen – kaum Unterschied macht, ob etwas (nennen wir es ‘Dings’), eine Methode (
node_name()) oder ein Attribut (nodeName) ist. - Eine
Replace in Filesaktualisiert meine PHP4-Skripts schnell, damit sie auf einem PHP5-System lauffähig sind. Die einzigen händischen Änderungen musste ich für das Laden und Speichern der XML-Datei vornehmen.
Es gibt noch andere ‘Seltsamkeiten’ beim Umgang mit PHP. Insgesamt kann man aber leicht zu folgender Einsicht kommen:
PHP sucks!
{ 4 } Comments
Da bist du aber ein wenig zu hart zu PHP! Dass manches in zusätzlich zu ladenden Paketen versteckt ist kennst du
auch von Java. Und dass es bei neuen Versionen auch einige neue Funktionen und Funktionsnamen gibt, hast du in HTML auch
– Stichwort “deprecated”! Oder verwendest du noch das <front>-Tag?
Ich finde PHP ziemlich praktisch, um auf die Schnelle einfache, dynamische Seiten generieren zu lassen. Der Vorteil
liegt in der Einbettung von HTML in PHP…
Zu hart zu PHP?
Module
Ich habe ja nichts dagegen, dass man bei PHP Module laden muss. Ganz im Gegenteil. Eine Einteilung in Module/Packete ist sinnvoll und hat sich zum durchaus erfolgreichen Konzept der komponentenbasierten Softwareentwicklung weiterentwickelt. Loose coupling und so.
Aber: bei PHP werden alle Module in denselben Namespace geladen. In Java muss man die Klassen eines Packets mit einem qualifizierenden Namen ansprechen (oder man verwendet
imports). Das ist in PHP nicht der Fall. Auf sowas wieimportbin ich in PHP noch nicht gestoßen. Bislang habe ich alle benötigten Module in derphp.iniquasi ‘freigeschalten’. Damit befindet sich dann alles aus dem Modul automatisch im ‘globalen’ Namespace und verschmutzt diesen. Es gibt – sinnvollerweise – eine Namespace-Bewegung in der PHP-Community: http://phpnamespaces.org/Gäbe es in PHP sowas wie
import, dann hätte ich auch schneller feststellen können, woher die XML-DOM-Klassen und Funktionen kommen.Ich denke auch, dass durch solche Verschmutzungen das von vielen IDEs angebotene AutoCompletion mit PHP nicht sonderlich gut funktioniert: Man stelle sich eine Liste von Methoden/Klassen/Funktionen/Variablen vor, die alle mit ‘a’ beginnen und mehrere Bildschirmseiten einnimmt.
Deprecated
Gegen die Einführung neuer Funktionsnamen ist auch nichts zu sagen. Solange die alten noch irgendwie funktionieren. In meinem Fall handelte es sich bei dem deprecated nicht um ein , sondern um ein . Ohne
display_errors = Onhätte ich das wohl nicht so schnell rausgefunden. Aber das einfach Abschalten von Funktionalität mag die Ausnahme sein.Embedded Code
Das Einbetten von PHP in HTML ist tatsächlich eine sehr interessante Sache. Nur, wenn du dir das mal überlegst, wiederspricht das solchen Design-Grundlagen wie dem Model-View-Controller-Prinzip: Die Darstellung (View) wird mit der Logik (Controller) verschmolzen. Das führt dazu, dass so ein embedded-PHP-Skript im Grunde schlecht zu warten ist. Man kann nur schlecht unterscheiden, ob man gerade Logik oder Darstellung vor sich hat. Ganz und gar unübersichtlich wird’s dann, wenn in einem Code-Block mittels
. In größeren PHP-Projekten (wie z.B. WordPress) gibt’s daher viele Dateien, in denen allein PHP-Code steht.
echooderprintHTML ausgegeben wird.Außerdem geht man in letzter Zeit zu etwas über, das Templating genannt wird: Man erstellt eine HTML-Schablone, in der Platzhalter für Variablenwerte angelegt sind. Die Werte stammen aus der – separaten – Logik. Das läuft dann ungefähr so ab:
Seitenanfrage -> Logik kontrolliert Autorisierung, etc., berechnet Werte, extrahiert Werte aus Datenbank und ruft schließlich ein Template auf, in das diese Werte übergeben werden -> Template ersetzt Platzhalter mit Werten.Diese Vorgehen ist sehr viel sauberer als embedded-Code (ob’s nun PHP, Java oder sonstwas ist).
Aber ich stimme dir zu – und bislang habe ich das auch so gemacht – für’s schnelle zusammenhacken einer dynamischen Seite eignet sich embedded-Code sehr gut. Das können aber andere Sprachen auch: z.B.: Java (JavaServerPages), aber auch Python (Django, PythonServerPages). Wegen letzterem habe ich mir kürzlich auch einen eigenen httpd geleistet – wie berichtet.
Auch PHP kann templating (z.B. mit Smarty. Deshalb solltest (könntest) du dir das auch mal anschauen – bei Gelegenheit. Ich würde es dir zumindest empfehlen. In Sachen Webentwicklung ist das ein Schritt nach vorne. Versprochen.
Meine Linkliste unter PHPSucks habe ich inzwischen übrigens etwas erweitert.
Vor ein paar Tagen habe ich mir Snakes and Rubies runtergeladen. Ein Video, in dem die Macher von Django (Python) und RubyOnRails (Ruby) u.a. über ihren Werdegang berichten. Beide haben mit PHP angefangen (natürlich). Beide sind umgestiegen. Ich denke, es hat sich gelohnt…
Naja also display_errors sollte man eigentlich zu Testzwecken und bei der Entwicklung sowieso immer an haben. Das mit dem globalen Namespace ist schon nicht so prall, stimmt. Allerdings hast du das bei C auch. Java, C# und die ganzen höheren Programmiersprachen hingegen verwöhnen einen mit ihrem durchdachten Sprachdesign und sinnvollen Konzepten.
Aber solche Sachen sind der Preis für die Einfachheit der Sprache. Mir sind einige Dinge an PHP auch lästig, vor allem die misslungene Typisierung, aber wenn man vernünftig und modular entwickelt, mit Templates arbeitet und soweit möglich in Klassen kapselt (seit PHP5 erst richtig möglich), ist das Arbeiten mit PHP imho sehr angenehm. Gerade auch die häufige Diskussion was Sicherheitslücken angeht, ist meistens schlampigem Programmierstil anzulasten, dem PHP zugegebenerweise durch sein Sprachkonzept nicht gerade entgegenwirkt.
Beileid Kollege,
der Schlussfolgerung kann ich nur zustimmen
Post a Comment