minidom nodes without a document?

[Magnus Lie Hetland]

Is it possible to build a minidom tree bottom-up without access to a
document node? It seems that simply instantiating the various node
classes doesn't quite do the trick...

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Is it possible to build a minidom tree bottom-up without access to a
document node? It seems that simply instantiating the various node
classes doesn't quite do the trick...

No. In the DOM, all nodes always belong to a Document. They don't have
to be part of a hiearchy, though - you can create unattached Element
nodes with createElement[NS], and put them in a hierarchy as you like.

Regards,
Martin

 

[Levente Sandor]

Is it possible to build a minidom tree bottom-up without access to a
document node? It seems that simply instantiating the various node
classes doesn't quite do the trick...

I'm not sure what you mean exactly by "without access to...". You need
a Document instance to create the elements, but they aren't added
automatically to it.
.... foo.appendChild(doc.createElement('bar'))
....

 

[Magnus Lie Hetland]

(e-mail address removed) (Magnus Lie Hetland) wrote in message


I'm not sure what you mean exactly by "without access to...". You need
a Document instance to create the elements, but they aren't added
automatically to it.

[snip]

Right. I understand this. Thanks to you and Martin for mentioning it,
though

My problem is that I'm building the DOM as part of a bottom-up parse,
where the various subtrees are build independently from each other,
through callbacks that are set as part of the parser. So... For all of
these to have access to a document object (so they can use the
createFoo methods) I'd have to either (1) hard-code a document into
the parser (meaning, basically, that each parser instance can only be
used once), or (2) refactor the parser to supply a context object to
each callback (which could be, for example, the document object).

I guess the latter is the way to go, but it does seem awkward that it
should be necessary. In my case it's OK, as the parsing code is part
of my project, but if I used an external parser, I'd have to create a
separate AST and then translate that into a DOM tree afterward; a bit
unnecessary...

Oh, well. Can't argue with the DOM, I suppose

 

[Martin v. =?iso-8859-15?q?L=F6wis?=]

(1) hard-code a document into
the parser (meaning, basically, that each parser instance can only be
used once)

I would do this, and provide a reset() operation.

I guess the latter is the way to go, but it does seem awkward that it
should be necessary.

You don't *have* to do that - you could also create stand-alone node,
providing __init__ parameters as necessary. In that case, you would
bind yourself to a specific DOM implementation, though - and we do
reserve the right to change the constructor parameters across releases
(in fact, we did that in the past).

Regards,
Martin

 

[John J. Lee]

(e-mail address removed) (Magnus Lie Hetland) wrote in message


I'm not sure what you mean exactly by "without access to...". You need
a Document instance to create the elements, but they aren't added
automatically to it.

[snip]

Right. I understand this. Thanks to you and Martin for mentioning it,
though

My problem is that I'm building the DOM as part of a bottom-up parse,
where the various subtrees are build independently from each other,
through callbacks that are set as part of the parser. So... For all of

[...]

You want DocumentFragment.

But Martin's right (of course): you still need a Document, and you
make fragments by calling Document.createDocumentFragment().

For a headache-inducing example of the use of this (my headache, not
yours, I hope ;-), see

http://wwwsearch.sf.net/DOMForm/


(the parser is in the file DOMForm/_js.py -- it gave me a headache
because everything prior to a chunk of embedded script in HTML has to
be available to the script through the document object, so sometimes
you have to append to a DocumentFragment, sometimes to a node in the
main Document tree)


John