Diskussion:Document Object Model

aus Wikipedia, der freien Enzyklopädie
Letzter Kommentar: vor 13 Jahren von Vanger in Abschnitt zum Abschnitt "Lückenhaft"
Zur Navigation springen Zur Suche springen

Es bezeichnet eine Datenstruktur, die von der OMG (Object Management Group) definiert wurde, insbesondere zur Darstellung von XML-Daten in Programmen. -- Ist der Satz korrekt? -- sk 08:22, 10. Dez 2003 (CET)

Eigene Überschrift für die Implementationen

[Quelltext bearbeiten]

Ich wäre dafür die Implementationen unter einer eigene Überschrift aufzuführen. Außerdem sollte auch ein Link zur jeweiligen Sprache in der Wikipedia führen. --Rbb 13:00, 22. Jun 2004 (CEST)

Meiner Ansicht nach sollten Wikipedia Artikel auch für Laien nachvollziehbar und einfach verständlich sein. Diese Vorausetzungen erfüllt dieser Artikel nicht. Vielleicht kann man doch ein paar Zeilen mehr verlieren und dafür die Anzahl an Weblinks verringern. Rec 22:27, 15. Sep 2004 (CEST)

:schließe mich dieser Meinung an. Dieser Artikel bedürfte dringend einer Vereinfachung --132.180.48.160 11:12, 8. Aug 2005 (CEST)

Entwurf Überarbeitung

[Quelltext bearbeiten]

Habe begonnen, den Artikel zu überarbeiten und vor allem ein Beispiel angeführt. Im Lauf der nächsten Wochen will ich das Thema weiter voranzutreiben - ich bin aber für Unterstützung/Feedback/Fragen immer dankbar.

Offen bisher noch:

  • Abschnitt Implementierungen: Hier sollte ein kurzer Überblick für die wichtigsten Implentierungen für spezielle Programmiersprachen gegeben werden
  • Aufräumen Weblinks: Unterscheidung zwischen Links zu DOM selbst und Links zun Implementierungen, Reduktion der Anzahl
  • Verweis, Abgrenzung zu SAX

Exilfranke 12:01, 13. Aug 2005 (CEST)

Standards, recommendations, etc.

[Quelltext bearbeiten]

Englishen Artikel sagt dass DOM Level 1, 2 wurden nur im Jahre 2005 als W3C Recommendation genannt. Trotzdem, diese Artikel sagt, dass DOM wurde im Jahre 1998 als W3C Standart genannt. Wer hat Recht? --VictorAnyakin 10:35, 19. Jul 2006 (CEST)

Da eine Empfehlung nicht dasselbe wie ein Standard ist, vermutlich beide. --217.7.68.91 11:02, 7. Sep. 2007 (CEST)Beantworten

DOM - API.

[Quelltext bearbeiten]

Ist es denn korrekt zu sagen, dass das DOM eine API ist? Ich habe mal bei der englischen Version nachgesehen und da heißt es: "Document Object Model (DOM) is a description of how an HTML or XML document is represented in a tree structure. DOM provides a structure that facilitates access to the elements of an HTML or XML document by scripting languages with object oriented features (e.g., JavaScript).". Das trifft es meiner Ansicht nach eher, denn auf der Grundlage der Baumstruktur (also des DOM) kann eine API entwickelt werden. Das DOM ist also ein Modell auf der Basis einer Baumstruktur und Grundlage für verschiedene APIs. Oder liege ich da falsch? --Sschlarb 19:27, 3. Dez. 2006 (CET)Beantworten

Dem kann ich mich anschließen. Der DOM ist das Dokument in Objektstruktur. Die API ist (wie der Name sagt) die Schnittstelle, um auf den DOM zuzugreifen. Der DOM ist nicht die API, die API wird von DOM bereitgestellt. --Sevenclev 14:50, 4. Sep. 2007 (CEST)Beantworten
Sogar als Laie konnte ich nachlesen, daß es auch in anderen Sprachen (c++) APIs zum Manipulieren oder Auslesen des DOM gibt.--Wikipit 15:52, 5. Jan. 2010 (CET)Beantworten
Ganz korrekt es ist keine API. Es gibt zwei vom W3C definierte "Language bindings", eine für Javascript und eine für Java, das sind dann API's. --JJCool 00:21, 17. Jun. 2010 (CEST)Beantworten

BOM (Browser Object Model)

[Quelltext bearbeiten]

Ich habe vorhin einen Artikel zum BOM (Browser Object Model) angelegt, das zwar keine W3C-Recommendation ist, aber anscheinend in der einen oder anderen Form von den gängigen Webbrowsern unterstützt wird. Könnte vielleicht jemand, der gut über diese Materie Bescheid weiss, diesen neuen Artikel mal anschauen, ergänzen, oder eine Rückmeldung auf der Diskussionsseite hinterlassen, ob das BOM überhaupt eines eigenen Wikipedia-Eintrags würdig ist? Danke! --Hub 22:33, 18. Mai 2009 (CEST)Beantworten

DOM ./. HTML-Baum

[Quelltext bearbeiten]

Warum wird die HTML-Struktur einer html-Seite mit Tabelle so bedeutend und in Form eines Stammbaums dargestellt, aber im DOM-Baum (rechte Seite des Artikels) nicht eingearbeitet? Jedenfalls finde ich hier überhaupt keinen Bezug zu der exorbitanten HTML-Darstellung links.--Wikipit 16:03, 5. Jan. 2010 (CET)Beantworten

ich kann hier nicht folgen --suit 17:44, 5. Jan. 2010 (CET)Beantworten
Das Beispiel links (reine HTML-Struktur und DOM), welches eine Tabelle beschreibt, stimmt mit dem DOM-Knoten-Diagramm rechts nicht überein, was aus didaktischer Sicht nicht gut ist. Klar? Ein Beispiel, wie JS auf DOM zugreift (object.xxx), wäre auch hilfreich.--Wikipit 13:54, 24. Jan. 2010 (CET)Beantworten

DOM und img-tag

[Quelltext bearbeiten]

Ich finde gar keinen Einstieg, wie sich das img-Element im DOM repräsentiert.--Wikipit 16:03, 5. Jan. 2010 (CET)Beantworten

wie jedes andere HTML-Element auch? --suit 17:44, 5. Jan. 2010 (CET)Beantworten

Baustein schlimmer als Artikel

[Quelltext bearbeiten]

Der Artikel mag nicht das gelbe vom Ei sein aber der Baustein ist daneben

  1. DOM hat nichts mit XML-Parsing zu tun
  2. XPath baut direkt auf DOM auf
  3. Es gibt keine Alternative zu DOM als Darstellung für XML/HTML-Dokumente

--JJCool 00:12, 18. Mai 2010 (CEST)Beantworten

  1. DOM ist eine Serialisierungsform einer Knotenstruktur, XML lässt sich idR. in DOM ubertragen und umgekehrt.
  2. XPath baut nicht auf DOM auf, XPath ist eine Abfragesprache für XML-Strukturen und hat mit DOM prinzipiell mal nichts am Hut. Eine in DOM übertragene XML-Struktur lässt sich aber notwendigerweise mit DOM-Methoden traversieren, genausogut kann man aber auch gleich direkt mit XPath drüberrattern und den Baum zusammenstutzen. Ebenso lassen sich mittels CSS-Selektoren Knoten in einer XML-Struktur eindeutig adressieren - DOM oder XPath sind nicht die einzigen Lösungen. Zudem ist man nicht auf CSS angewiesen um CSS-Selektoren nutzen zu können, entsprechende Engines gibt es z.B. auch für JavaScript (Sizzle, Peppy).
  3. XML ist bereits eine Darstellunsform für Knotenstrukturen, DOM ist eine andere Darstellunsform und bietet zugleich eben auch Methoden zur Abfrage und Navigation an. Weitere denkbare Alternativen um eine DOM- oder XML-Struktur darzustellen sind z.B. mehrdimensionale Arrays oder eine Mehrdimensionale Objektbäume. Jede halbwegs taugliche Programmiersprache kann sowas - in python nennt sich das z.B. marshalling. Ein anderes verbreitetes Format wäre z.B. JSON, ist aber ansich auch nur ein mehrdimensionales Array. HTML ist übrigens wie XML ein SGML-Dialekt.
--suit 16:52, 2. Jun. 2010 (CEST)Beantworten
  1. Wir sind also einig, dass DOM nichts mit Parsing zu tun hat sondern eine eine Objektrepräsentation eine XML-Dokuments ist. Deshalb ist in meinen Augen der Kommentar "Passagen suggerieren, dass DOM zum XML-Parsing vorteilhaft wäre" am Thema vorbei.
  2. Vielleicht bin ich zu sehr Techniker aber sag mir mal eine andere Implementierung des XML-Infoset ausser DOM. Oder einfacher gesagt bei allen mir bekannten XPath-Implementierungen bestehen die Ergebnisse eine XPath-Ausdrucks aus DOM-Knoten. Ausserdem ist es ja nicht Aufgabe den "Baum zusammenstutzen" sondern ihn im Memory zu repräsentieren.
  3. XML ist eine serialisierte Baumstruktur - DOM ein abstraktes API zum Zugriff auf die Baumstruktur. DOM schreibt keinerlei Implementierung vor es bleibt also dem Entwickler freigestellt als Datenstruktur hinter dem DOM-Interface "mehrdimensionale Arrays oder eine Mehrdimensionale Objektbäume" zu verwenden.

--JJCool 01:48, 13. Jun. 2010 (CEST)Beantworten

  1. Nein, DOM hat sehrwohl etwas mit dem Parsing zu tun (natürlich auch mit der Darstellung im Speicher oder mit der Manipulation) - man kann ein XML-Dokument in DOM überführen und dann mittels DOM-Methoden parsen. Das Parsing selbst ist dann nicht notwendigerweise XML -> DOM sondern DOM -> wasauchimmerichdamitmachenmöchte - z.B. eine SQL-Abfrage zum Befüllen einer Datenbank oder was auch immer.
  2. PHP Simple XML erzeugt per XPath einen Objekt-Array-Baum - DOM ist hierbei nicht notwendig um irgendwas zu erreichen. Die Aufgabe von XPath ist sehrwohl den "Baum zusammenzustutzen" bzw. eine Untermenge daraus zu extrahieren. Die Aufgabe von DOM hingegen ist es, ihn im Speicher abzubilden ODER entsprechende Untermengen zu entnehmen - und genau das wird im Artikel wirr gemischt nud nicht klar dargestellt. Zudem wird eben suggeriert, dass DOM das "Non plus ultra" in Sachen "entnehmen von Schnittmengen aus einem Baum" sei.
  3. DOM war ursprünglich dazu gedacht, HTML in einem abstrakten Modell dazustellen um es "live" manipulieren zu können - natürlich hast du recht, dass es reduziert nur als "API" gedacht war - mittlerweile ist DOM aber weit mehr, aber auch weit langsamer als moderne implementierungen. XPath weist zu DOM aber einige signifikante Unterschiede auf - z.B. wie Attributknoten behandelt werden. Das merkt man spätestens dann wenn man ein mittels einfachen DOM-Methoden und ein mittels einfachen XPath-Abfragen zerlegtes Dokument in eine andere Struktur z.B. eben ein Array überführt. --suit 12:37, 14. Jun. 2010 (CEST)Beantworten

Wir reden derartig aneinander vorbei, dass ich die Diskussion hier abbreche --JJCool 00:15, 17. Jun. 2010 (CEST)Beantworten

  1. Was Beschreibt dieser Artikel? Die DOM API's oder das DOM von w3c? Also ich würde ja auf w3c tippen, dann hat DOM aber weniger mit Parsen zu tuen! Denn w3c beschreibt nur den Baum der im Speicher repräsentiert wird, wie die API's das umsetzen (und einige nennen sich dummerweise auch DOM) ist eine andere Sache, zumal man dann auch auf die Sprach spezifischen Eigenheiten der API's eingehen sollte. Wenn man ein XML Dokument Parst, (zum beispiel mit Java) kann ich es in ein Document Object Model überführen (Also XML -> DOM). Man kann aber auch eine API wie SAX (Java) nutzen, mit der könnte man dann XPath umsetzen. Letzten Endes sind DOM und XPath nur Modelle mit denen man auf XML (Und HTML etc.) Dokumente zugreifen kann. DOM macht das Über die komplette Baumstruktur, die bei Parsern somit immer komplett geladen wird. XPath macht das via Punktuellen zugriff, was ein suchen und ersetzen viel leichter und schneller macht als bei der DOM welches immer den Ganzen Baum im speicher haben will.-- 02:49, 30. Nov. 2010 (CEST) (ohne Benutzername signierter Beitrag von 188.108.162.127 (Diskussion) )

Ich kann mich der Überschrift nur anschließen.

  1. DOM hat nichts mit Parsen zu tuen. DOM steht für Document Object Model. Es ist somit ein Modell und zwar ein Objekt-Modell für Dokumente. DOM spezifiziert wie man das Objekt-Modell in Bezug auf Struktur und Inhalt verarbeiten kann. Aber die Voraussetzung dafür, ein Objekt-Modell überhaupt bearbeiten zu können ist, dass man eine XML-Datei bereits vollständig geparst also syntaktisch und semantisch analysiert haben muss. Das bedeutet, dass zu dem Zeitpunkt, an dem man sich über ein DOM Gedanken machen kann, der Parser bereits beendet ist. Das DOM entspricht einem AST, den ein Parser als Output seiner Tätigkeit erzeugt. Und somit ist es völlig zutreffend, dass ein DOM nichts mit Parsen zu tuen hat, da ein DOM das Ergebnis eines Parsen ist.
  2. Das XPath direkt auf DOM aufbaut halte ich allerdings für eine unzulässige Vereinfachung der Allgemeinheit. Es mag ein nahe liegender Implementationsansatz für eine XPath-Implementation sein, diese auf Basis eines DOM zu machen. Es ist aber keineswegs so, dass diese Art der Implementation zwangsläufig so ist. Anstelle deine XML-Struktur mit Hilfe einer DOM-Schnittstelle zu speichern, kann man das XML-Dokument auch zerlegt in einer SQL-Datenbank speichern und XPath in SQL implementieren.
  3. Das DOM was mit Darstellung zu tuen hat, ist ebenfalls Unsinn. Das Document Object Modell ist ein Modell dafür, wie man auf eine XML-basierte Baum-artige Datenstruktur zugreifen kann, um sie auszulesen oder zu verändern. Mit Darstellung hat das überhaupt nichts zu tuen, es sei denn man fotografiert die Speicher-Riegel in seinem Computer.

Vielleicht sollten die ganzen selbsternannten DOM-Experten hier mal die Spezifikation lesen. Bereits im ersten Absatz würde man dort auf folgenden Satz stoßen: The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. Somit sollte klar sein, dass es sich weder um eine Syntaxanalyse noch um eine Darstellung, sondern um eine Programmierschnittstelle handelt, der eine Annahme über eine Baum-artige Datenstruktur zu Grunde liegt. -- Ceving 18:06, 13. Dez. 2010 (CET)Beantworten

Donald Duc k

[Quelltext bearbeiten]

muss man hir wirklich diese besch. disnay figur nehmen?? wie währs mit jemand anderen z.b. Jimmy Wales oder jemand anderen...

Donald Duck find ich aufjedenfall scheiße!!!!

--93.204.42.184 13:52, 2. Jun. 2010 (CEST)Beantworten

Abschnitt "Benennung"

[Quelltext bearbeiten]

Im Abschnitt Benennung steht:

Bei der Bezeichnung "Document Object Model" handelt es sich eigentlich um eine Fehlbenennung, da DOM nicht als Modell, sondern als Schnittstelle (Interface) für den definierten Datenzugriff definiert ist und vom W3C auch so bezeichnet wird.

Ein Objektmodell definiert u.a. aber auch Schnittstellen. Von daher kann man DOM als Objektmodell bezeichnen. Siehe dazu auch: W3C - Was ist DOM? und W3C Glossar - Objektmodell.

--TOWPlayer 12:02, 22. Dez. 2010 (CET)Beantworten

zum Abschnitt "Lückenhaft"

[Quelltext bearbeiten]

Dort steht: "... Allerdings sind andere Abfragesprachen wie etwa XPath hinsichtlich Bedienkomfort, Umfang und Leistungsfähigkeit seit Jahren wesentlich besser als DOM ...".

Im Abschnitt "Standardisierung des DOM" wird dagegen unter der Überschrift "DOM Level 3" die Spezifikation "DOM 3 XPath" erwähnt. Die Dokumentation dazu findet man unter: http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html . Dort wird eine Abbildung des DOM auf das von XPath verwendete Baummodell (das dem DOM-Baum ähnlich ist) beschrieben um XPath Funktionen im Rahmen des DOM-Frameworks zu ermöglichen. Der Punkt 1.4 beschreibt das Interface. Die "Abfragesprache" XPath ist also innerhalb des DOM-Frameworks spezifiziert. Dann kann aber auch XPath nicht besser sein als DOM und auch nicht umgekehrt.

Ich schlage daher vor, den Abschnitt "Lückenhaft" zu löschen, da m. E. die dort behauptete Lücke nicht vorhanden ist.. Gibt es Bedenken?

Pmatu 20:14, 24. Jan. 2011 (CET)Beantworten

Der Baustein als Ganzes entbehrt sich der Grundlage, da will nur einer dass seine persönliche Meinung eingebaut wird... Mir ist jedenfalls keine WP:BLG genügende Kritik bekannt die DOM angreifen würde und hinstellt dass XPath das Ultima Ratio wäre - wie auch, beide lassen sich zu vollkommen unterschiedlichen Dingen nutzen und haben andere Zielsetzungen. Die Wikipedia macht keine wertenden Vergleiche so lange es nicht erhebliche und relevante Kritik in der Welt der Webentwicklung gäbe - das aber ist schlicht nicht der Fall. --Vanger !!? 21:29, 24. Jan. 2011 (CET)Beantworten