Facebook
Twitter
Google+
Kommentare
5

DOMDocument::schemaValidate

Ich liebe das DOMDocument und ich bin mir sicher, dass es auch nicht anders geht. Ich liebe es sogar so sehr, dass ich glaube, man sollte eine eigenen Rubrik für dieses kleine hinterhältige Ding entwerfen. DOMDocumentHatesMe.com oder so ähnlich wäre natürlich auch ein Kracher. Aber jetzt mal wieder ernst. Ich glaube die Entwickler dieser diversen Klassen haben sie ziemlich jeden Fehler gemacht, den man machen konnte beim entwerfen eines solchen „Tools“. Ok man muss dazu sagen, dass es – glaube ich zumindest – die erste Klassensammlung in PHP war. Davor war das meiste oder sogar alles in Funktionen gepackt. Wenn wir das ganze also optimistisch betrachten, war es der Schritt in die richtige Richtung. Aber dieser Blog wäre nicht dieser Blog, wenn wir Optimisten wären.

Was wollen wir also machen? Wir haben ein XML File und wollen dies gegen ein XSD validieren. Klingt ganz einfach, denn die Methode schemaValidate macht genau dies. WIr laden also ein wohlgeformtes XML File in unser DOMDocument und validieren gegen das Schema xyz.xsd. Im Code würde die wie folgt aussehen:

<?php
    $doc = new DOMDocument('1.0', 'utf-8');
    $doc->loadXML($xml);
    $docIsValid = $doc->validateSchema( 'xyz.xsd' );

    if( $docIsValid ) {
      echo 'valid';
    } else {
      echo 'not valid';
    }
?>

Da diese Methode laut Dokumentation einen boolschen Wert zurückliefert, kann diese Snippet auch einwandfrei funktionieren. Und das tut es auch. Warum ich mich trotzdem aufrege werdet ihr euch jetzt natürlich fragen.In der Standard Installation unseres Servers (Ubuntu) gibt es mit der Funktion das Problem, dass sie, sobald das XML Dokument nicht gültig ist, direkt die ungültigen Bereiche als Text auf der „Konsole“ ausgibt. Falls man also damit rechnet, dass ein XML auch mal ungültig sein kann passiert es natürlich, dass unschöner Output mit in die Seite gerendert wird.

Ich hoffe mal für PHP, dass dies irgendein Problem der Installation ist, denn ich kann mir nicht vorstellen, dass es tatsächlich beabsichtigt sein kann, eine Methode mit boolschen Rückgabewert trotzdem noch den Standard Output bemüht um zu kommunizieren. Würde ja eigentlich genau gegen der Trennung von Code und Design sprechen, da man dort Ausgaben an einer Stelle hat, die sich mitten in der „Logik“ befindet. Aber wie immer gilt: Die Wege des PHP sind unergründlich … oder so ähnlich.

Über den Autor

Nils Langner

Nils Langner ist der Gründer von "the web hates me" und auch der Hauptautor. Im wahren Leben leitet er das Qualitätsmanagementteam im Gruner+Jahr-Digitalbereich und ist somit für Seiten wie stern.de, eltern.de und gala.de aus Qualitätssicht verantwortlich. Nils schreibt seit den Anfängen von phphatesme, welches er ebenfalls gegründet hat, nicht nur für diverse Blogs, sondern auch für Fachmagazine, wie das PHP Magazin, die t3n, die c't oder die iX. Nebenbei ist er noch ein gern gesehener Sprecher auf Konferenzen. Herr Langner schreibt die Texte über sich gerne in der dritten Form.
Kommentare

Ein Kommentar

  1. Hi,

    das muss wohl an deiner Installation liegen, ich habe es auf folgenden Kompilationen getestet und mit error_reporting(0) kam kein Output außer dem des Echos:

    PHP 5.2.5 selbstkompiliert m. Suhosin @ Debian 32 & 64 Bit
    PHP 5.2.0 Package aus Etch @ Debian
    PHP 5.2.4 selbstkompiliert m. Suhosin @ RedHat Linux 64 Bit

    Liebe Grüße,
    Timo

    Reply
  2. Quick’n’dirty ist auch ein

    $docIsValid = @$doc->validateSchema( ‚xyz.xsd‘ );

    möglich, um die Ausgabe der Fehlermeldungen zu unterdrücken.

    Will man es sauber machen, führt aber kein Weg an der eigenen Fehlerbehandlung vorbei.

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen