DOMDocument::schemaValidate

Lesetipps

1. DOMDocument::ConfuseMe();
2. Genie oder Wahnsinn: DomExceptionDecorator
3. ReFUCKtoring

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.

5 Kommentare »

• 
  

  Timo

  am 13. Oktober 2008 um 18:39 Uhr

  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

• 
  

  Arne Blankerts

  am 21. Oktober 2008 um 12:28 Uhr

  Moins,

  einfach das libXML error handling selbst übernehmen:

  http://php.net/libxml

  und schon is “Ruhe” im Karton.

  CYA,
  Arne

• 
  

  Actron

  am 22. Oktober 2008 um 22:55 Uhr

  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.

• 
  

  admin

  am 23. Oktober 2008 um 06:44 Uhr

  Also mit @ fangen wir hier mal gar nicht erst an

• 
  

  PHP hates me - Der PHP Blog » DOMDocument::ConfuseMe();

  am 2. November 2008 um 08:03 Uhr

  [...] Nils ja auch schon aufgezeigt hat, ist eine der merkwürdigsten Klassen von PHP sicherlich DOMDocument. Dem möchte ich mich [...]

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar