- From: Marco <marco@tinet.com>
- Date: Wed, 28 Nov 2001 09:15:07 -0500 (EST)
- To: www-dom@w3.org
I'm relatively new to DOM, so perhaps I'm saying the obvious or I'm missing the point... After reading the latest DOM Level 2 HTML specification, it seems to me that the focus of DOM is to manipulate existing documents but not to create new ones from scratch. My goal is to create programmatically (x)html documents without worring about well-formness using classes that abstract the various elements instead of writing out raw tags, so I turned to DOM and its implementations (for example, the one included in Apache's Xerces). Here are some limitations I found: - HTMLDOMImplementation::createHTMLDocument creates only a bare html document: no way to create a xhtml document or to specify a DTD. OK, I can turn to the superclass (DOMImplementation), but I loose the HTMLDocument as resulting document (it's "only" a Document). - in HTMLDocument there are convenient methods to access some of the document's elements, but surprisingly lacks a method to easily access the HEAD element (that is created by HTMLDOMImplementation::createHTMLDocument) the way you can access the BODY element. - somewhere (probably in HTMLDocument) there should be methods to create instances of specific elements (for example, a createHTMLParagraphElement method). While a workaround exists via the method Document::createElement, the specification does not mandate (and I don't see how can it do it) that the new element must be of the right type (at least Xerces is smart enough to return a proper specific instance instead of a generic Element). Also, this has the drawback that you must specifiy the HTML tag, thus losing abstraction - methods that return instances of specific elements (as HTMLDocument::getBody) should have a specific return type: in the example HTMLDocument::getBody should return a HTMLBodyElement, not just a HTMLElement. Clearly, you can work around these and other limitations, but you loose flexibility and abstraction. Actually I'm using my own set of classes but this is obviously not the best solution, since it's (almost) always better to reuse classes already written (when available). Marco
Received on Wednesday, 5 December 2001 18:51:48 UTC