Re: URLRewriter and XHTML issue revisited

Hi Jake, all

This is all a little convoluted because the compiled instance of XMLObject is
a org.w3c.dom.Document, but it also contains a Document (the real DOM).
I am being a bit long winded because I had to remember how things were
put together and wanted to pass on the knowledge.

All of this could be made cleaner by more agressive refactoring that 
I was willing to do at the time (plus using some modern JVM features),
but probably best to wait until a new DOM implementation.

Now the problem arises in wanting to be able to do a Node.getDocument()
anywhere in the DOM and get back to the document.  However, this gives you the
contained document.  Not always what one wants.

The DOMFormatter package is suppose to be able to handle outputting any DOM,
not just XMLC compiled ones.  It can also formats subdocuments starting at any
noded.  For URL rewritting, it needs to be able to determine what attributes
can contain URLs, which isn't a part of the DOM API.  The DocumentInfo
interface is used to get this information, which is implemented by the
XMLObjectImpl.  So this means it needs to get from any node back to the XMLC
compiled class.

Getting from the contained DOM to the XMLObject DOM is not easy. A good
approach would have been to keep a map of weak references from the contained
object to the XMLObject; but since we were still trying to to support JVMs
which didn't have weak references. So the XMLObjectLink interface is create as
a hack to get from the contained Document back to the XMCObject instance.  I
guess it's also a way around not having multiple inheritance.

So the concrete class of the contained document is really a tiny class that
extends the Xerces Document.

So for example, we have (only some of the clases illustrated):

  UserDocumentClass
    extends HTMLObjectImpl
    implements HTMLObject, org.w3c.dom.html.HTMLDocument
       extends XMLObjectImpl

this contains a reference to the actual DOM, which is:

  XercesLinkedHTMLDocument
     extends org.enhydra.apache.html.dom.HTMLDocumentImpl
             implements HTMLDocument

which then has a pointer back to the UserDocumentClass object.

So for URLRewritting to work; BaseDOMFormatter needs to have the the XMLObject
Document, not the contained one.  It uses the XMLObjectLink object
to obtain this.

For a HTML document using the Xerces DOM, the DOm factory is:
        org.enhydra.xml.xmlc.dom.xerces.XercesHTMLDomFactory

for LazyDOM HTML documents:
        org.enhydra.xml.xmlc.dom.lazydom.LazyHTMLDomFactory

these classes both have createDocument() methods that create documents
that  implement XMLObjectLink; org.enhydra.xml.lazydom.LazyDocument
directly, and non-lazy Xerces documents via a wrapper class:

        org.enhydra.xml.xmlc.dom.xerces.XercesLinkedDocument

Well, XHTML documents result in an instance of 
        org.enhydra.xml.xhtml.dom.xerces.XHTMLDocumentImpl

which doesn't implement XMLObjectLink.

==============================================================================
So I am pretty sure the fix is to implement modify
        org.enhydra.xml.xhtml.dom.xerces.XHTMLDocumentImpl

to implement
         org.enhydra.xml.xmlc.XMLObjectLink

this most likely needs to be done for the wireless DOMs as well.

==============================================================================


Jacob Kjome <hoju@xxxxxxxx> writes:
> 
> Hi everyone (especially David and Richard),
> 
> I think this problem should be dealt with before the XMLC-2.2 full 
> release.  I'm not sure what the correct fix is?  If one of you can take a 
> look at the issue, that would be fantastic!
> 
> Jake
> 
> At 12:14 PM 5/21/2003 -0500, you wrote:
> 
> >Petr Stehlik brought this issue up a while ago and I don't think it ever 
> >got resolved.  Can we come to some resolution and fix this issue?  See...
> >
> >xHTML problem again
> >http://xmlc.enhydra.org/project/mailingLists/xmlc/msg02211.html