Re: Copying a node from one doc to another

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)

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

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
markup
so the templates are easy to read. Writing the file out as source took
very
few rules for indenting although it's not too sophisticated either.

Our source generator is a rewrite of an existing generator that produces
an
object-relational mapping layer. The reason we need to importNodes from
another document is that if we can specify templates for methods, we can
read
these at run time and merge them into our source document. This
functionality
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
Persistence).

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

Hope this is helpful,
Eric

>
>
> 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