DOM ist das sogenannte "Document Object Model", welches eine allgemeine Schnittstelle zu Dokumenten im XML-Format darstellt. Ich weiß nicht, inwiefern du mit XML oder expliziten XML-Umsetzungen (HTML ist im Grunde ja XML mit festgelegten Tags, Attributen usw) vertraut bist, aber jedes solch formatierte Dokument verfolgt ja einen klar-strukturierten Aufbau (genau deshalb gibt es ja überhaupt XML). DOM ist nun also eine Schnittstelle, welche Methoden bereitstellt, um ganz einfach an die vorliegenden Datensätze des Dokuments zu gelangen. Anhand von HTML lässt sich das glaube ich am besten beschreiben, wobei ein HTML-Dokument grundsätzlich ja folgenden Aufbau verfolgt:
<html>
<head>
<title>Der SeitenTitel</title>
</head>
<body bgcolor="#ffffff">
...
</body>
</html>
Ich habe also ein Dokument, welches einen HEAD-Teil, sowie einen BODY-Teil enthält. Der HEAD-Teil enthält Seitenattribute, während der BODY-Teil die Seitenbeschreibung enthält. Es ist also eine allgemeine Struktur erkennbar (ganz oben steht HTML, darunter HEAD und BODY als Unterelemente, welche wiederum Unterlemente haben können) und genau diese Struktur ist beschrieben im DOM. Es gibt dann verschiedene Level von DOM, unter anderem auch ein Level, welches sich der HTML annimmt. Es besteht damit die Möglichkeit, einen DOM-Parser zu programmieren, welcher diese Strukturen in Methoden umsetzt, um ganz einfach ein benötigtes Unterlement abzufragen, ohne den Quellkode des Dokuments vor den Augen zu haben.
Z.B. könnte ein DOM-Parser für HTML folgende Methoden bereitstellen:
Document getDocument(); um sich die gesamte HTML-Seite in ein Document-Objekt zu holen
Wenn dann das Document geholt ist, könnte dieses Document-Objekt wiederum folgende Methoden besitzen:
Header getHeader();
Body getBody();
Das Body-Objekt, könnte nun wiederum folgende Methoden bereitstellen:
Color getBGColor();
Da DOM eben eine allgemeine Schnittstellenbeschreibung zu dem Dokument ist, wäre es dem Parser egal, welche HTML-Seite er zur Bearbeitung übergeben bekommt, da alle Seiten dem DOM folgen (wenn sie W3C-konform programmiert wurden!). Ein solcher Parser würde also dann praktisch aus jeder übergebenen Seite z.B. die Hintergrundfarbe filtern können, ohne dass dies großartig kompliziert wäre und ohne dass der Anwender die eigentliche HTML-Seite zu Gesicht bekommen würde (er müsste eben nur getBGColor() aufrufen und hätte sofort die Hintergrundfarbe - in welcher Zeile genau diese Hintergrundfarbe im Quelltext formuliert ist, ist egal).
Ein DOM-Inspektor ist nun also ein DOM-Parser, welcher ein Dokument in seine einzelnen Bestandteile zerlegt (bei HTML z.B. HEAD,BODY - BODY könnte dann wieder TABLE beinhalten und TABLE TR usw.) und zur Anzeige bringt. Da es sich bei solchen Dokumenten immer um hirarchisch-aufgebaute Dokumente handelt (es gibt also ein Wurzelelement mit Unterelementen, welcher wieder Unterlemente besitzen usw), stellt ein solcher DOM-Inspektor das Dokument eigentlich immer als Baumstruktur dar, da ein Baum ja auch eine Wurzel besitzt, darunter Kinder usw...
Der Browser Firefox z.B. besitzt einen DOM-Inspektor für HTML-Dokumente, der eben nichts anderes macht, als eine HTML-Seite mit seinen Unterelementen, deren Unterelementen usw. als Baumstruktur darzustellen, so dass der Webseitenentwickler schnell erkennen kann, ob er Strukturfehler in seiner Seite hat (ein Unterelement taucht auf einmal an der falschen Stelle im Baum auf - besitzt also den falschen Vater).
Zur Beschreibung: bitte nicht schlagen, aber das war alles freimündig hergetippt. Sicher sind da einige falsche Beschreibungsteile drinnen, aber ich hoffe, dass der allgemeine DOM-Gedanke durchdringt. Wers dann ganz genau will, soll sich ein Buch kaufen
