[jdom-interest] DOMOutputter and other thoughts

[Kevin Regan]

Hmm, I didn't say it would be difficult, I just had some
questions about the interface... :-)

Basically, we just need to reverse the code in the DOMBuilder.
However, I'm still not sure why the DOMOutputter does not
need a DOMImplementation to build the DOM tree.  Furthermore,
I don't see how the adaptor classes can implement this.
Looking at DOM Level 2, there does not seem to be
a way to modify the DocumentType after the Document
is created (this is specifically documented as such):

------------------------------------------------------------------

public DocumentType Document.getDoctype()

     The Document Type Declaration (see DocumentType ) associated with
this document. For
     HTML documents as well as XML documents without a document type
declaration this returns
     null . The DOM Level 2 does not support editing the Document Type
Declaration, therefore
     docType cannot be altered in any way, including through the use of
methods, such as
     insertNode or removeNode , inherited from Node .

-------------------------------------------------------------------

Therefore, in order to copy the JDOM to the DOM,
you need to first create the DocumentType with a call
to DOMImplementation.createDocumentType() and
and then use the DOMImplementation.createDocument call to
actually create the document. In addition, the DOMOutputter class only
takes a DOM Document. There is no way to change this reference to
something else and no way to set any DocumentType information.

I think the best way to go about this is to have DOMOutputter
take a DOMImplementation.  Then, the user can create a DOM
tree with any implementation that he likes.

By the way, I was not sure what you meant by the distinction
between a DOM tree and DOM document.  Can you clarify what
you meant?

--Kevin


On Mon, 12 Jun 2000, Brett McLaughlin wrote:

> philip.nelson at omniresources.com wrote:
> > 
> > I now have a desire/need for this as well so here are my 2 cents
> > 
> > > > I've been taking a look at the DOMOutputter class
> > > > and it seems that this will need to take a
> > > > org.w3c.dom.DOMImplementation rather than a
> > >
> > > Nope - use the JDOM adapters to get a Document from a specific
> parser
> > > implementation. Nobody is familiar with DOMImplementation anyway...
> > >
> > 
> > BUT .. if the eventual goal is to create a JDOM specific parser AND
> JDOM
> > will support DOM, isn't a JDOM DOMDocument implementation the best way
> to do
> 
> JDOM does not and will never /support/ DOM. It will talk to DOM and from
> DOM, nothing else.
> 
> > it?  Before I realized that someone else had started this I had
> started
> > thinking about it and had come to the same conclusion as Kevin.
> Certainly,
> > using the adapters would be easier.  For a version 1 release you could
> do
> > something as simple as using XMLOutputter to create a XML string and
> then
> > use an adapter to produce the DOM tree.  I'm not sure how much slower
> that
> 
> No. You get an empty Document object from  the DOM Adapaters, and then
> populate that Document with Nodes, generated from the JDOM objects.
> 
> > would be than manually creating the DOM tree but the API wouldn't have
> to
> > change to implement it with the manual DOM building step so there
> isn't a
> > huge downside.
> 
> The mapping from JDOM to DOM is simple - I would do it myself, but I
> have no time - I'm not sure if Kevin thinks about it differently, as he
> seems to think it is harder than it is ;-)  If I get time, I'll do it on
> the plane Friday - I really don't think it should take more than 3
> hours...
> 
> -Brett
> 
> > 
> > > > One other thought, just a pie-in-the-sky idea, was to have the
> > > > JDOM classes implement the DOM interface so that they could be
> > > > used directly by DOM applications:
> > > >
> > > Nope. Already went down that road, and vetoed it heavily. Bad news
> > > (trust us, JDOM alpha 1 was like that, and James Davidson convinced
> us
> > > otherwise.)
> > 
> > I agree.  One of the great things about JDOM is that each class is so
> small.
> > I would rather have this separated into a separate set of DOM
> implementation
> > classes.
> > _______________________________________________
> > To control your jdom-interest membership:
> >
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@you
> rhost.com
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@you
> rhost.com
>