This strategy will fail at runtime when: You parse a document and attempt to cast an element of that document to MyElement when that element has not been fully expanded. It will throw a ClassCastException. Reason being: Until it is fully expanded, the element represented is not an instance of ElementImpl but an instance of DeferredElementImpl. DeferredElementImpl is not a subclass of ElementImpl and ElementImpl is not a subclass od ElementImpl. They are in separate heirachies. Moreover there is no public constructor for DeferredElementImpl or its superclasses. Ditto for the *NS heirachies.
On the other hand: If you construct a DOM from scratch, adding instances of your subclasses to the model, that will work and serialize just fine. ie your can write but not read effectively. Like you I wish this were not so. I will be following this thread with interest. -----Original Message----- From: Andy Clark [mailto:[EMAIL PROTECTED] Sent: Thursday, 13 December 2001 11:09 p.m. To: [EMAIL PROTECTED] Subject: Re: Fast Nodes Tobias McNulty wrote: > So basically there isn't anything I can do to extend Xerces other > than going into the its source and creating a custom > createNodeIterator function? No, there's nothing stopping you from extending the Apache DOM implementation. And you don't have to deal with all of the Deferred* node types. For example: public class MyElement extends ElementImpl { public MyElement(DocumentImpl doc, String name) { super(doc, name); } } public class MyDocument extends DocumentImpl { public Element createElement(String name) { return new MyElement(this, name); } } [NOTE: I didn't check this for errors.] And then just set the document-class-name property on the parser so that it uses your document class for making the DOM nodes as it parses. But depending on what you want to do, you may have to be careful about what you override, etc. > >help to try subclassing the "deferred" heirarchy. The truth is that xerces > >implementations are so tightly dependent on the xerces framework that > >extension is hardly worth the effort. That's hardly accurate. But there is a little bit of complexity introduced for the benefit of memory and runtime performance. So either we are too simple and slow which people don't like; or we're fast but too complex which people don't like. Oh well... -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
