DOMDocument und PHP5

[Felix Riesterer]

Lieber molily,

Er hat Unit-Tests und folgt dem HTML5-Standard. Für das HTML-Parsing von libxml2 existieren vermutlich Unit-Tests, aber er folgt m.W. keinem Standard (weder SGML noch XML noch HTML5).

also sagst Du in Klartext übersetzt: Konzeptionell und herstellungstechnisch ist er dem in der DOMDocument-Klasse verwendeten libxml2 offensichtlich überlegen.

Das kann ich Dir glauben. Das wäre tatsächlich ein Argument, dass ich das Teil einsetze.

Lieber wäre mir in solchen Fällen, ich könnte alles in eine Datei übertragen

Was heißt »in eine Datei übertragen«?

Soll heißen: Durch einen wie-auch-immer-Automatismus die einzelnen PHP-Dateien des Parser-Projektes in eine Datei "minifizieren", damit ich in meinem Projekt nur eine PHP-Datei "pflegen" und inkludieren muss.

Mir ist klar, dass für "open source" eine derart verunstaltete PHP-Datei nicht pflegbar oder sinnvoll debug-bar ist, aber bei JavaScript-Projekten verwendet man doch auch mitunter minifizierte (oder uglifizierte) Code-Dateien. Warum sollte ich mir aus dem Projekt nicht eine derartige Datei generieren? Noch schöner wäre, das Projekt hätte soetwas bereits fertig im Angebot. Wenn die aber lieber mit einem anderen Automatismus namens Composer arbeiten, dann muss der Vorteile haben, die sich mir noch nicht erschließen.

Tausende Zeilen Code in eine PHP-Datei zu schreiben ist eher ein Zeichen von schlechtem Code.

Das mache ich nur, wenn ich externe libs verwende, die ich nicht selbst pflege, sondern die ich plug&play-artig in mein Projekt einbinden will. Was sollte daran verwerflich sein?

Dem Code des HTML5-Parsers sieht man an, dass er modern ist: Er folgt aktuellen Coding-Guidelines, nutzt Namensräume und pro Klasse eine Datei, lässt sich mit dem Composer installieren.

Das mit dem Composer habe ich noch nicht verstanden. Meine PHP-Fähigkeiten haben mit PHP 4.3 angefangen. Danach habe ich mich (im Wesentlichen über Mitlesen im Forum) nach und nach an eine objektorientierte Schreibe bei PHP gewöhnt (in JS gelang mir das früher, das Ergebnis war der Artikel, bei dessen Veröffentlichung Du mir tatkräftig unter die Arme gegriffen hattest). Trotzdem bin ich noch weit von "aktuellen Coding-Guidelines" entfernt, und was "der Composer" ist, kann ich nur erahnen. Sicherlich ist es eine Art Mischung aus PHP-Autoloading und einer anderen Art des gezielten Inkludierens von benötigten Script-Dateien. Zeit müsste man haben, das alles selbst zu studieren, dann verstünde ich nicht nur, was der Composer ist, sondern könnte ihn vielleicht selbst in meinen Projekten einsetzen...

Klar, das ist aufwändiger Code, aber HTML-Parsing ist kein Kinderspiel.

"Die Class" darf gerne so umfangreich wie notwendig sein. In meinem Projekt will ich sie auf übersichtliche Art einbinden können, ohne dass mir mein eigener Code in dem ganzen Fremdbibliotheken-Krams untergeht. Ein bisschen fürchte ich, früher oder später den Wald vor lauter Bäumen nicht mehr zu sehen.

wie der Parser, den mir Tom mit simple_html_dom schon angeboten hatte.

[...] simple_html_dom sieht wie ein dilettantischer Parser aus, der nicht einmal eine Finite State Machine nutzt, sondern teilweise reguläre Ausdrücke. Robust und technisch korrekt wäre ein HTML5-Parser,

Schon klar. Ich habe damit experimentiert, um von meinen eigenen RegExen etwas weg zu kommen. Nun möchte ich weiter in der Richtung studieren, um mein aktuelles Projekt besser und robuster zu machen. Mein erster Überraschungsmoment war HTMLTidy, welches mit HTML5 nur Mist angestellt hat. Dann dachte ich, naja, nehme ich doch DOMDocument als "Ersatz" und baue meinen HTML-Code als echtes DOM. Dann kann DOMDocument dafür sorgen, dass das Ergebnis valide und wohlgeformt ist, dann kann ich auf HTMLTidy völlig verzichten. Sogar eine Art "pretty printing" hätte ich mit DOMDocument bekommen können... aber gut. Dann schaue ich in den von Dir vorgeschlagenen Parser.

Liebe Grüße,

Felix Riesterer.