Ja. Wirklich. Noch ein Blog über PHP, HTML, CSS, MySQL, JavaScript, das Web und so weiter. Diesmal von
mir.
In erster Linie hilft schreiben ja auch dem Denkprozess, aber wenn die Artikel dann schonmal da sind...

JavaScript hat ein paar merkwürdige Variablen-Zustände, die, wenn man JavaScript so wie ich nur ab und zu einsetzt, einem immer wieder starkes Kopfzerbrechen bereiten. Man möchte nur kurz einen Wert im DOM ändern oder eine Plausibilitätsprüfung einbauen, wird aber von dem lustigen kleinen gelben Ausrufezeichen links unten im Browser geärgert. Da ich davon jetzt die Schnauze voll habe, habe ich mich hingesetzt und mich endlich einmal damit ausseinandergesetzt wie man
null,
undefined und
NaN ausseinanderhält und zuverlässig darauf prüft.
Der Wert
null wird relativ selten von JavaScript-Operationen selbst erzeugt. Er kann jedoch dazu verwendet werden einen "leeren" Zustand einer Variablen zu markieren. Darauf lässt sich leicht mit dem Operator
=== prüfen:
var leer=null;
if (leer===null) { ... }
Der Wert
undefined schlägt einem schon öfter entgegen, unter anderem wenn Variablen nicht initialisiert werden, ein Funktionsparameter nicht übergeben wird oder eine nicht existierende Objekt-Eigenschaft abgefragt wird. Kurz gesagt ist
undefined das Pendant zu
NULL in PHP. Zuverlässig prüfen lässt sich darauf mit
typeof():
if (typeof(unbekanntevariable)=="undefined") { ... }
Wenn es um Objekteigenschaften oder bereits sicher deklarierte Variablen geht, funktioniert auch der direkte Vergleich (ohne Quotes):
var ob={};
if (ob.unbekannteeigenschaft==undefined) { ... }
Damit lassen sich auch optionale Funktionsparameter mit Defaultwert erzeugen:
function alertNumber(number)
{
if (number==undefined) number=0; // Gibt 0 aus wenn Argument nicht gegeben wurde
alert(number);
}
In der ersten Variante würde
if (unbekanntevariable==undefined) ... nicht funktionieren, da der JavaScript-Fehler bereits vor dem Vergleich, nämlich beim Auswerten von
unbekanntevariable ausgelöst wird.
Den Wert
NaN (Not a Number) spuckt JavaScript immer dann aus wenn ein Wert, der keine Zahl ist, in einem numerischen Zusammenhang verwendet wird. Darauf lässt sich zuverlässig nur mit einem kleinen Hack prüfen:
var num=parseInt("Hallo");
if (typeof(num)=="number" && num+""=="NaN") { ... }
In verschiedenen Foren findet man immer wieder Tipps auf
null,
undefined oder
NaN mit einem simplen
if (variable) { ... } zu prüfen, was aber z.B. bei einem Integer mit Wert 0 oder einem Leerstring nicht funktioniert.

Nach einem Projektumzug vor ein paar Wochen von einem stabilen aber langsamen Projekt auf zwei Servern zu einer totalen Apokalypse mit Load-Zahlen von 50 an der Tagesordnung auf vier (!) Servern habe ich nun endlich herausgefunden dass PHP 5.1.6 ganz großer Mist ist.
Leider konnte ich nicht 100%ig herausfinden was genau das Problem war. Sicher ist das PHP 5.1.6 noch das
SimpleXML-Problem hat bei dem ein Speicherloch im Zusammenhang mit
foreach auftritt. Dieses lässt sich relativ leicht lösen in dem der Node vor dem
foreach kopiert wird:
// Speicherloch
foreach($node->books as $book) ...
// Funktioniert gut
$books=$node->books;
foreach($books as $book) ...
Danach ging's ein wenig besser, einzelne Maschinen fielen trotzdem wegen zu hohem Load aus. Vor ein paar Tagen wurde auf PHP 5.3.1 aktualisiert, seitdem läuft alles stabil. Ich kann also empfehlen immer eine aktuelle Version von PHP zu verwenden. Bei einigermassen vernünftigem Code lassen sich Anwendungen auch schnell
kompatibel einstellen.

Wie ich heute nach einem Serverumzug und anschliessender langer Suche feststellen musste, ist die Direktive
AddDefaultCharset bei aktuellen Apache-Installationen von Red Hat standardmässig eingeschaltet, in der
httpd.conf. Angegeben sind einmal ISO-8859-1 und einmal UTF-8. Diese Direktiven sorgen dafür dass Text- und HTML-Dateien mit dem entsprechenden Charset im Header gesendet werden, wenn man sich nicht selbst um den Header kümmert. Die meisten Browser ignorieren dann ein eventuell im META-Tag angegebenes Charset, was zu viel Verwirrung führen kann, da man das Problem nicht im Quellcode erkennen kann, aber trotzdem nur noch Unsinn in der Datenbank landet wenn man z.B. gerade ISO-8859-2 verwendet.
Mir erschliesst sich der Sinn dieser Aktion nicht so ganz, denn eigentlich halte ich es für sinnvoller das zu verwendente Charset an die Applikation oder die einzelnen Dateien zu binden und nicht an den Server. Nach dem Auskommentieren der beiden Zeilen lief alles wie vorher.