hasematzel.de » PHP http://hasematzel.de/blog webstandards, entwicklung, internet, kultur Thu, 24 Jun 2010 07:00:20 +0000 en hourly 1 http://wordpress.org/?v=3.0 Variablen aus PHP per JSON in JavaScript übergeben http://hasematzel.de/blog/2010/02/06/variablen-aus-php-per-json-in-javascript-uebergeben/ http://hasematzel.de/blog/2010/02/06/variablen-aus-php-per-json-in-javascript-uebergeben/#comments Sat, 06 Feb 2010 20:32:24 +0000 Oliver http://hasematzel.de/blog/?p=757 Es passiert mir recht oft, dass ich in einer Applikation im JavaScript-Layer auf die Werte von Variablen zugreifen muss, die eigentlich nur in PHP existieren. Meist habe ich mir in PHP ein Wörterbuch angelegt, welches Standardbegriffe enthält, die an vereinzelten Stellen in der Applikation verwendet werden. Zum Beispiel werden Fehlermeldungen (“konnte nicht gespeichert werden”, “bitte Feld %s ausfüllen”) in einer einzigen Datei zusammengefasst und zum notwendigen Zeitpunkt abgerufen und angezeigt. Das ermöglicht mir unter anderem später eine Lokalisierung der Applikation.

Ich beginne im Normalfall immer mit dem Backend (PHP) und setze erst später den Client-Layer (JavaScript) um. Das meiste JavaScript ist dann eine Verbesserung der Usability. Nicht selten brauche ich an manchen Stellen im JavaScript auch eine Fehlermeldung, die aber nur in PHP existiert.

Der Holzhammer

Die einfachste Methode ist der print() der Variable direkt in das JavaScript:

<?php
$error = 'Es ist ein Fehler aufgetreten';
?><!DOCTYPE html>
<html lang="de">
<head>
...
    <script type="text/javascript">
    var error = '<?php echo $error; ?>';
    alert(error);
    </script>

Die Methode ist effektiv, hat aber gehörige Nachteile:

  1. Ich habe manchmal nicht die Möglichkeit, mit PHP noch im HTML/DOM rumzuwerkeln. Manchmal will ich sie auch gar nicht haben.
  2. Diese Lösung verursacht eine Sprach-Suppe, die nur sehr schwer zu betreuen ist.
  3. Bei grösseren Wörterbüchern kommt man hier ganz schön ans Schwitzen.

Etwas eleganter: Ein bisschen JSON

Die JavaScript-Objekt-Notation, kurz JSON genannt, bietet einen etwas eleganteren Weg, auch grössere Mengen von Variablen von PHP in JavaScript zu transferieren:

<?php
$errors = array(
    'errnosave' => 'Speichern fehlgeschlagen',
    'errunknown' => 'Unbekannter Fehler');
?><!DOCTYPE html>
<html lang="de">
<head>
...
    <script type="text/javascript">
    var errors = '<?php echo json_encode($errors); ?>';
    alert(errors.errunknown);
    </script>

Diese Methode hat schon einige Vorteile, aber immer noch ein paar Nachteile:

  1. Ich kann schon einige Daten an JavaScript übertragen. Das JSON-Format ist genial kurz und erzeugt für diese Aufgabe fast keinen Overhead.
  2. Nachteil: Ich muss immer noch direkt ins Dokument schreiben.

Erzeugen einer eigenen dictionary.js

Diese dritte Variante bemüht sich, einfach, aber so abstrakt wie möglich den Variablentransfer durchzuführen. Wir brauchen dafür drei Dateien und – wenn möglich – einen Cron, der regelmässig das Wörterbuch erzeugt.

Datei Nr. 1: Die dictionary.ini

In der dictionary.ini werden die Variablen abgelegt. Eine ini-Datei, weil man sie aus PHP heraus mit der Funktion parse_ini_file() so schön lesen und weiterverarbeiten kann. Eine ini-Datei ist ein einfaches Textdokument und kann so aussehen:

; Statische Meldungen
[authentication]
variable = 'Wert'
variable2 = 'Wert2'

[errors]
errnosave = 'Es wurde nicht gespeichert'
errunknown = 'Unbekannter Fehler'

Den Aufbau kennt man z. B. von den Smarty-Config-Dateien.

Datei Nr. 2: Der Parser create_dictionary.php

Ich kann meinen Parser in der Datei create_dictionary.php nun anweisen, die ini-Datei einzulesen und dabei die Sektionen (in den eckigen Klammern) zu berücksichtigen:

<?php
$dictionary = parse_ini_file('dictionary.ini', true);
$errors = $dictionary['errors']; // Sektion 'errors' ermitteln
?> 

Die dritte Datei: dictionary.js

Nun kann ich den Array $errors im JSON-Format in eine Datei namens dictionary.js schreiben:

<?php
$data = sprintf('var DICT = %s', json_encode($errors));
$h = fopen('dictionary.js', 'w');
fwrite($h, $data);
fclose($h);
?>

Diese dictionary.js-Datei kann ich nun ganz normal im <head>-Bereich meiner HTML-Seite einbinden und habe Zugriff auf das DICT-Objekt:

<!DOCTYPE html>
<html lang="de">
<head>
...
    <script type="text/javascript" src="dictionary.js"></script>
    <script type="text/javascript">
    alert(DICT.errunknown);
    </script>

Auch diese Methode kommt nicht ganz ohne Nachteile daher:

  1. Ich muss aus PHP in eine dictionary.js schreiben können, manchmal will man das aus Sicherheitsgründen nicht.
  2. Ich will eine solche Schreiboperation nicht bei jedem Request auf die Applikation durchführen. Ich muss das also per Cronjob oder immer in einem Build machen.

Dennoch ist die Variante “schön” genug, um in einzelnen Fällen und gerade in Web-Applikationen die Übermittlung von Variablen von PHP zu JavaScript zur Leichtigkeit werden zu lassen.

]]> http://hasematzel.de/blog/2010/02/06/variablen-aus-php-per-json-in-javascript-uebergeben/feed/ 2 Snow Leopard und Apache, PHP und MySQL http://hasematzel.de/blog/2009/09/10/snow-leopard-und-apache-php-und-mysql/ http://hasematzel.de/blog/2009/09/10/snow-leopard-und-apache-php-und-mysql/#comments Thu, 10 Sep 2009 11:28:27 +0000 Oliver http://hasematzel.de/blog/?p=695 Die Veröffentlichung von Apples neuer Betriebssystem-Version Snow Leopard hat für Web-Entwickler auch einige Neuerungen mitgebracht. Unter anderem wurde auch der Apache und die PHP-Version aktualisiert. Wer wie ich nicht MAMP verwendet, hat eventuell ebenfalls eine böse Überraschung erlebt: Die angepasste Apache-Konfiguration und alle PHP-Einstellungen sind nach einem Update einfach weg, bzw. zurückgesetzt.

Nach wie vor lässt sich der docroot des Webservers über ein http://localhost/~username aurufen, aber PHP läuft dort nicht mehr und ein installiertes MySQL unter /usr/local/ ist auf den ersten Blick auch nicht mehr da. Was ist passiert?

Der neue Apache

Der Apache Webserver wurde auf die Version 2.2.11 aktualisiert. Damit wurden jedoch die Einstellungen in der httpd.conf und vor allem unter /extra/httpd-vhosts.conf zurückgesetzt. Das bedeutet, trotz eines mitgelieferten PHP 5.3 funktionieren PHP-Dateien im docroot unter /Users/{username}/Sites/ erstmal nicht. Eine Abhilfe schafft ein kurzer Sprung in die Konsole, um in der Apache-Konfiguration das Laden des PHP-Moduls wieder zu aktivieren (Bei solchen Sachen lohnt es sich, immer mal ein Backup der aktuellen Konfiguration anzulegen):

#~> sudo cp /private/etc/apache2/httpd.conf .
    ~/backup/httpd.conf.20090909.001
#~> sudo vi /private/etc/apache2/httpd.conf

In der Datei suchen wir nach der Zeile, in der das PHP-Modul geladen wird. Die Zeile muss etwa so aussehen:

#LoadModule php5_module    libexec/apache2/libphp5.so

Durch Entfernen des vorangestellten #-Zeichens und einem Neustart des Apaches wird nun das PHP-Modul geladen. Danach sollte eine im docroot des Webservers abgelegte PHP-Datei mit dem Aufruf der Funktion phpinfo() brav die nagelneue Version 5.3 anzeigen.

Aktivieren der php.ini

Bei einem Blick in die Aufstellung in der PHPInfo stellen wir fest, dass keine php.ini-Datei geladen wird. Stattdessen verwendet das Modul die Standardeinstellungen. Im Verzeichnis /private/etc/ finden wir aber mehrere inaktive Versionen, die wir schnell aktivieren können:

#~> ls /private/etc/php.in*
/private/etc/php.ini.default
/private/etc/php.ini-5.2-previous
/private/etc/php.ini.default-5.2-previous
#~> cd /private/etc/
#~> sudo cp php.ini.default php.ini
#~> sudo chmod u+w php.ini
#~> sudo apachectl restart

Jetzt können wir an der Datei Änderungen vornehmen. Eine wichtige Neuerung in PHP5.3 ist sicherlich das Date/Timezone-Objekt. Das wirft nämlich massenweise Kompatibilitätsfehler aus, wenn Applikationen noch mit den date()-Funktionen von PHP5.2 und kleiner arbeiten. Um diese Fehler zu verhindern, sollte in der php.ini zumindest die Standard-Timezone gesetzt werden. Die unterschiedlichen Angaben (für Europa) findet man in der PHP-Dokumentation. Man öffnet die php.ini, sucht die Definition für date.timezone im Abschnitt [date], setzt den Wert entsprechend (bei mir Europe/Berlin) und kommentiert die Zeile aus. Nach Speichern der Datei und eines Neustarts des Apaches sollten die Fehler verschwunden sein. Ich rate jedoch jedem Entwickler, sich die Definition des neuen Date/Timezone-Objektes anzusehen.

MySQL

Ich hatte vorher eine eigene MySQL-Installation unter /usr/local/mysql laufen. /mysql war dabei ein symbolischer Link auf die Bibliotheken unter mysql-5.0.1a-osx10.5-x86. Das Snow Leopard Update hat zwar die Bibliotheken wiederhergestellt, aber den symbolischen Link vergessen:

#~> cd /usr/local/
#~> sudo ln -s mysql-5.0.1a-osx10.5-x86 mysql

Nebenbei sollte ich die MySQL-Version vielleicht auch einmal aktualisieren – zunächst mal klappt aber wieder der Zugriff über den Client.

PHP kann aber noch nicht auf MySQL zugreifen. Zunächst sind in der php.ini die entsprechenden mysql-Module freizuschalten (im Bereich Dynamic Extensions). Danach erscheint der Abschnitt MySQL zwar wieder brav in der phpinfo, es konnte jedoch immer noch keine Verbindung zur lokalen Datenbank hergestellt werden. Das liegt daran, das in der php.ini.default der Wert für das mysql.default_socket auf /var/mysql/mysql.sock steht. In meiner Installation liegt das Socket aber unter /private/tmp/mysql.sock. Schnell den Wert ändern, Apache neu starten und der Zugriff auf die lokale MySQL-DB klappt wieder:

mysql.default_socket = /private/tmp/mysql.sock
mysqli.default_socket = /private/tmp/mysql.sock

Von meinen virtuellen Hosts hatte ich ausreichend Backups, darum war die Wiederherstellung der httpd-vhosts.conf nicht so schwer. Wer lokale TLDs verwendet und die Zugriffe durch Einträge in der /private/etc/hosts ermöglicht, muss übrigens die hosts-Datei nicht noch einmal anfassen: Die Einträge darin werden von Snow Leopard übernommen.

Danke für die Hilfe

Sehr viel geholfen haben mir dabei die Einträge von tady im WordPress-Forum und der Artikel Snow Leopard: Umstiegshürden eines Web-Entwicklers in Wookkies Blog. Danke dafür.

]]> http://hasematzel.de/blog/2009/09/10/snow-leopard-und-apache-php-und-mysql/feed/ 9 FirePHP als Debugger für PHP und Ajax einsetzen http://hasematzel.de/blog/2009/04/18/firephp-als-debugger-fuer-php-und-ajax-einsetzen/ http://hasematzel.de/blog/2009/04/18/firephp-als-debugger-fuer-php-und-ajax-einsetzen/#comments Sat, 18 Apr 2009 06:40:21 +0000 Oliver http://hasematzel.de/blog/?p=578 Jeder Entwickler benötigt einen Debugger. Abhängig von Programmiersprache und Entwicklungsumgebung gibt es unzählige Möglichkeiten, die Ausführung der entwickelten Applikation zu überwachen. Entwickler von Webapplikationen haben dabei oft das Problem, dass sie eine ganzheitliche Lösung brauchen, um über mehrere Ebenen zu debuggen: Das Backend (meist eine Mischung aus Datenbank und Skriptsprache), ggf. im Backend auch noch Schnittstellen zu Drittsystemen und zusätzlich das Frontend, dabei den statischen und dynamischen Anteil – zumeist JavaScript. Bei der Verwendung von asynchronen HTTP-Anfragen zurück ins Backend wird es noch komplizierter: Die Antwort auf den Request hat im Grunde keinen Platz für Log- oder Fehlermeldungen. Klar, man kann sich die Meldungen in der HTML-Seite ausgeben lassen oder man parst den Rückgabewert noch einmal durch das JavaScript. Oder man lässt den AJAX-Prozessor ins Fehlerlog des Webservers schreiben und überwacht dieses parallel auf der Kommandozeile per tail.

Alle diese Methoden bedeuten aber vermehrten Aufwand bei der Erzeugung (und später auch wieder bei der Entfernung) der Meldungen. Insbesondere steigt beim Einsatz verschiedener Mechanismen die Gefahr, dass die Debugger irgendwie ihren Weg in den Produktivcode finden, weil man nicht aufpasst.

Debugging PHP im Browser

Für die weit verbreitete Skriptsprache PHP gibt es auch anspruchsvollere Lösungen: Der Zend Debugger wird oft verwendet, findet auch in PDT Einsatz. Das Aptana Studio (ebenfalls ein Eclipse-Derivat) hat ein eigenes Firefox-Addon, welches sich jedoch leider ziemlich mit dem unverzichtbaren Firebug beisst. Allerdings besteht bei allen Helferlein das Problem, über die oben angesprochenen Ebenen hinweg zu überwachen. Christoph Dorn hat sich deshalb hingesetzt und eine feine Lösung gebaut: FirePHP. FirePHP ist eine weitere Firefox-Extension, die ein zuvor installiertes Firebug benötigt und dann im Firebug-Stil die Meldungen des im Backend vorhandenen Debuggers ausgibt.

Was brauche ich?

Die Liste der notwendigen Tools ist kurz, die Installation trivial:

Die weiteren Beispiele beziehen sich der Einfachheit halber auf die standalone-Version. Im Grunde reichen zwei Zeilen Code, um FirePHP ans Laufen zu bringen:

<?php

require dirname(__FILE__) . '/extlib/firephp-0.2.1/fb.php';
FB::log(array('Peter','Paul','Mary'), 'Names');

?>

Hat man die beiden Addons Firebug und FirePHP im Mozilla Firefox installiert und das Tracking für Konsole und Netzwerk eingeschaltet, bietet sich in der Firebug-Konsole ein wunderschönes Bild:

Screenshot: FirePHP in der Firebug-Konsole

Magie! Doch das ist noch nicht alles. Neben unterschiedlichen Nachrichtenarten (log, info, warn, error) gibt es unzählige weitere Einsatzmöglichkeiten. Unter anderem fängt FirePHP auch Exceptions und lässt sich über ein Singleton auch als Objekt verwenden, um Traces zu bauen oder tabellarisch Inhalte anzuzeigen.

Debugging AJAX-Handler per FirePHP

Der Clou an der Sache: FirePHP portiert die Nachrichten über den HTTP-Header (gut, irgendwie müssen sie ja zum Browser kommen). In JSON-Syntax wird die entsprechende Meldung übermittelt. Das bedeutet, dass auch nachgelagerte Anfragen (AJAX) und deren Algoritmen brav in die Konsole schreiben. Ich muss mich also – gerade bei kleinen Projekten – nicht verbiegen, um die sonst so stillen Listener zum Reden zu bringen.

Screenshot: JSON-Syntax im HTTP-Header

So kann ich das console-Objekt vom Firebug munter mit dem FB::-Debugger mischen und mir aus allen Teilen der Applikation Meldungen sichtbar machen.

Mischung Firebug und FirePHP

Vorsicht beim Deployment!

Die Verwendung ist natürlich auch nicht ungefährlich. Man will unbedingt verhindern, dass derartige Meldungen und die Debug-Anweisungen irgendwo in einem Produktiv-System landen (das ist wohl bei jedem Debugger so). Aus diesem Grund benötigt man einen strengen Mechanismus, der auf Unaufmerksamkeit böse reagiert. Ein vernünftiger pre-commit hook im Versionierungssystem bietet sich an. Wer seine Webapplikation z. B. per Ant bauen lässt, kann in seiner build.xml eine entsprechende Sicherheitsabfrage unterbringen. Für die Überprüfung bietet sich z. B. der phpCodeSniffer an, der sich wiederum im pre-commit hook einsetzen lässt. Dazu gibt es eine großartige Zusammenfassung von Ronny Ristau.

]]> http://hasematzel.de/blog/2009/04/18/firephp-als-debugger-fuer-php-und-ajax-einsetzen/feed/ 0 Der Campfire-Chat und eine API in PHP http://hasematzel.de/blog/2008/02/08/der-campfire-chat-und-eine-api-in-php/ http://hasematzel.de/blog/2008/02/08/der-campfire-chat-und-eine-api-in-php/#comments Fri, 08 Feb 2008 19:58:31 +0000 Oliver http://hasematzel.de/blog/2008/02/08/der-campfire-chat-und-eine-api-in-php/ 37signals haben sich schon vor längerer Zeit von einer Webagentur zu einem Application Service Provider gewandelt. Dabei vermieten sie Webapplikationen, die zu ihrem eigenen Nutzen entstanden sind und nun der Öffentlichkeit zur Verfügung stehen.

Seit heute nutze ich neben Backpack noch einen weiteren Service der Agentur 37signals, für den ich Geld ausgebe: Campfire. Campfire ist ein webbasierter Chat, der besonders Entwickler bei den täglich anfallenden Aufgaben unterstützt. Ich nutze Campfire schon sehr lange als Werkzeug zur Absprache und als besseren Instant Messenger. Der Grund für die Entscheidung, für den Service zu bezahlen, kam durch die schon länger zurückliegende Beitragsreihe “Behind the scenes…” im Blog der Firma. Darin stellten die Jungs eindrucksvoll vor, wie sie ihre eigenen Produkte im täglichen Arbeitsprozess verwenden.

Zusätzlich habe ich eine inoffizielle Campfire-API entdeckt, die den Zugriff auf Chaträume per PHP und CURL ermöglicht. Icecube (so der Titel) bietet dabei genau das, was ich mir vorstelle. Rein in einen Raum, kurzes Paste und wieder raus. Genau richtig für einen post-commit hook in Subversion oder die Statusmeldung eines Systems a la twitter. Garrett Dimon hatte zeitweise mal einen freien Campfire-Raum als Kommentarersatz für seine Blogbeiträge. Ein Ansatz, den ich persönlich ziemlich gut finde. Mal schauen, vielleicht gibt’s auf hasematzel.de auch bald mal ein Kommentar per Chat live mit dem Autor.

]]> http://hasematzel.de/blog/2008/02/08/der-campfire-chat-und-eine-api-in-php/feed/ 0 OCI_COMMIT_ON_SUCCESS http://hasematzel.de/blog/2008/01/23/oci_commit_on_success/ http://hasematzel.de/blog/2008/01/23/oci_commit_on_success/#comments Wed, 23 Jan 2008 14:38:43 +0000 Oliver http://hasematzel.de/blog/2008/01/23/oci_commit_on_success/ Mehr oder weniger ein Hinweis an mich selbst. PHP und Oracle haben die eine oder andere Hürde im Zusammenspiel. Nicht immer kann man von Fehlermeldungen auf die Ursache schliessen.

Verwendet man dann noch ein Datenbank-Abstraktionslayer (z. B. AdoDB), kann die Fehlersuche bisweilen haarsträubend sein. Der Fehler: Use of undefined constant OCI_COMMIT_ON_SUCCESS… entsteht höchstwahrscheinlich aufgrund eines fehlendes –with-oci8=… in der Kompilierung von PHP. Einfach mal einen Blick in die phpinfo(); werfen.

Das hat mich ein wenig Zeit gekostet. Ein Forumsbeitrag im Symfony-Forum brachte schliesslich die Erlösung. Hmpf.

]]> http://hasematzel.de/blog/2008/01/23/oci_commit_on_success/feed/ 0