XOM API for Processing XML with Java

[Hallvard Trætteberg <hal AT idi.ntnu.no>]

Hi,

I've done something similar for JDOM and the same problem occurred
there: I think it was setAttribute that created new attributes with a
standard constructor instead of giving a chance for a specific factory
to create it. One possibility is to make Document implement NodeFactory
(or return a NodeFactory) and use it for creating all kinds of nodes if
needed outside of the building process. E.g. copy would call
getDocument.copy(element) or something like that. There should at least
be a way to change the behavior, so the method shouldn't be final.

The other part, handling detachment is also important. In JDOM I make my
Element subclass override setParent, which gave access to both the old
and new context. In this case, there is no need to actually change the
original behavior, just ensure that custom code is run in this case. So
detach may still be final, but any code that changes the parent could
call checkParentChange(oldParent, newParent) or something similar.

Hallvard Trætteberg, 1.amanuensis ved Inst. for datateknikk og
informasjonsvitenskap ved NTNU
www.idi.ntnu.no/~hal, mailto:hal AT idi.ntnu.no phone:+47 7359 3443, 


> -----Original Message-----
> From: xom-interest-bounces AT lists.ibiblio.org 
> [mailto:xom-interest-bounces AT lists.ibiblio.org] On Behalf Of 
> Marc Ramsey
> Sent: 11. september 2003 01:28
> To: xom-interest AT lists.ibiblio.org; Elliotte Rusty Harold
> Subject: Re: [XOM-interest] Subclassing Element
> 
> 
> > >NodeFactory provides a very convenient mechanism for building 
> > >documents using application-specific subclasses of Element.  Two 
> > >Element/Node methods
> > >which I'd like to override to create usable subclasses, 
> detach() and
> copy(),
> > >are currently declared final.  Is there any possibility that these 
> > >can be changed to non-final in a future release?
> > >
> >
> > You're going to have to provide a convincing use-case for 
> that if you 
> > want me to consider it.
> 
> In my particular case, I'm creating subclasses of Element to 
> build indices of id attributes on subtrees, and to provide 
> other functionality, like accessors for non-string Attribute 
> values.  I could do this by using a parallel model tree 
> structure where each node references the corresponding 
> Element, but subclassing Element is quite a bit simpler.
> 
> The API documentation for NodeFactory states that:
> 
>    Subclassing this class allows builders to produce instance 
> of subclasses
>    (for example, HTMLElement) instead of the base classes.
> 
> The definition of Element.copy() is:
> 
>     public final Node copy() {
>         return new Element(this);
>     }
> 
> Clearly, any time an element is copied, any subclasses of 
> Element created via a NodeFactory subclass will be replaced 
> by a generic Element.  For instance, calling copy() on a 
> Document will always result in a document built from 
> Elements.  Obviously, I could subclass Document, and add 
> myCopy methods to my subclasses. But, if a future release of 
> XOM uses copy() in an unanticipated circumstance (as in 
> CanonicalXMLSerializer), it may cause problems.
> 
> I'd like to override the detach() method primarily to allow 
> clean management of subtree indices stored within Element subclasses.
> 
> Thanks,
> Marc
> 
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org 
> http://lists.ibiblio.org/mailman/listinfo/xom-> interest
>