[Xerces-J] suggestion

[tb...@debis.com]

Hi,

the DOMParser class provides the following properties and methods

  public static final String DEFAULT_DOCUMENT_CLASS_NAME
  private String fDocumentClassName
  protected void setDocumentClassName(String documentClassName)
  protected String getDocumentClassName()

to change the document factory used in a subclass of DOMParser. The new
factory (which must be a subclass of DocumentImpl) is dynamically
created via Class.newInstance .

I like the flexibility provided by this mechanism.

Is there any possibility to implement this pattern in DocumentImpl in a
future release of Xerces-J too? That would enable a subclass of
DocumentImpl to produce subclasses of ElementImpl when its
createElement-method is called. ElementImpl already contains a
no-parameter-constructor to enable instantiation via Class.newInstance
(initializing it in another method call).

Having a DOM tree consisting of nodes derived from ElementImpl would
enable these nodes to contain some additional information (e.g.
references on event listeners triggered when a special action is applied
on that node (that is my special case at the moment)).

If there is no chance to find this feature in a future release,
ElementImpl should provide a copy-constructor (no deep copy, just copy
references) to use subclasses in a factories createElement method.

If your resources are too limited to satify such very special wishes
there would be no problem to implement it myself. I am an experienced
Java programmer but I never worked in a "Bazar project" like Xerces (how
to bring code fragments into the repository, does CVS work through
filewalls , ... ?)

Ciao, Bens.
______________________________________________________________________
      _______
     / __   /____________ ______
    / /_/  // __  /     //     /\        Thomas Bensler
   /   ___// /_/ /      7  ___/_/       debis Systemhaus GEI
  / __    7  ___/  /   /___    /\     Lademannbogen 21-23
 / /_/   /  /  /  /   /       / /    D-22339 Hamburg
/_______/_____/__/___/_______/ /   fon: +49-40-5395-1879
\_______\_____\__\___\_______\/   net: tbensler@debis.com

Re: [Xerces-J] suggestion

[Andy Clark <an...@apache.org>]

tbensler@debis.com wrote:
> Is there any possibility to implement this pattern in DocumentImpl 
> in a future release of Xerces-J too? That would enable a subclass 
> of DocumentImpl to produce subclasses of ElementImpl when its

If you're looking for a way to use DocumentImpl as a base and
provide your own version of ElementImpl, it's not too hard to
do. Here's a quick example:

  import org.apache.xerces.dom.DocumentImpl;
  import org.apache.xerces.dom.ElementImpl;
  import org.w3c.dom.Element;

  public class MyDocumentImpl extends DocumentImpl {

      public Element createElement(String name) {
          return new MyElementImpl(name);
      }

      public class MyElementImpl extends ElementImpl {
          public MyElementImpl(String name) {
              super(MyDocumentImpl.this, name);
          }
      }

  }

It might be a little overkill to have methods for all of the
various node types in order to set them by name. And the
current DOM implementation would only be able to use node
objects that derive from our *Impl classes.

-- 
Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org