W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2000

Re: Copying a node from one doc to another

From: Eric Richardson <maxwell@telesoft.com>
Date: Tue, 14 Mar 2000 16:08:11 -0700
Message-ID: <38CEC65B.10EE8C6@telesoft.com>
To: DOM <www-dom@w3.org>

keshlam@us.ibm.com wrote:

> > Since you're using Sun's DOM, you should be able to use the
> >     DocumentEx.changeNodeOwner (Node)
> > I like that better than the DOM L2 approach of
> >     Document.importNode (Node)

I wanted to let you know what I'm doing just in case it's useful for
continuing work. The extension will suit me for the time being until I
move to

We are building a Java source generator. The DOM provides the generic
in-memory representation of the Java Source file. We read a XML template
file into the DOM
for the main file and then add fields, and methods. Then we perform
substitutions such as the classname all using very simple DOM
procedures. When
generation is complete then the file is printed out. We minimized the
so the templates are easy to read. Writing the file out as source took
few rules for indenting although it's not too sophisticated either.

Our source generator is a rewrite of an existing generator that produces
object-relational mapping layer. The reason we need to importNodes from
another document is that if we can specify templates for methods, we can
these at run time and merge them into our source document. This
is specifically for providing relationship coupling methods between the
Persistent classes. This is very similar to the result of tools that
allow you to map tables to Enterprise Java Beans, specifically CMP
(Container Mapped

The hope is that bugs can be fixed in the templates rather than in

Hope this is helpful,

> We did consider this alternative. A problem arose when we started looking
> at the HTML DOM and some other proposed usecases, precisely because they
> _might_ have subclass-specific per-instances data. In the HTML DOM that
> includes Objects, Applets, scripts, etc. It wasn't clear what the
> interaction with those should be (does the applet continue running, does
> its context change, and if so how do we inform it of those changes), and it
> wasn't clear how to make the behavior when moving across implementations
> (or subclasses of implementations) consistant with moving within an
> implementation, so we went with a clone-analogy rather than a move-analogy.
> There's a proposal on the table to introduce something more like move in
> DOM Level 3. It might still be a clone-and-discard if you're crossing
> implementations boundaries, but it would provide an opportunity for
> optimization in those cases where the DOM can recognize a compabable node.
> I haven't seen a description of how the above issues are to be addressed,
> so I have no guess about whether it'll fly or not.
> ______________________________________
> Joe Kesselman  / IBM Research
Received on Tuesday, 14 March 2000 18:10:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:06 UTC