[jdom-interest] Re: Factories for Element creation

[David Churchville]

----- Original Message -----
From: "Jason Hunter" <jhunter at collab.net>
To: "Dave Churchville" <dmc at chimerasoft.com>
Cc: <jdom-interest at jdom.org>
Sent: Wednesday, November 01, 2000 11:02 AM
Subject: Re: [jdom-interest] Re: Factories for Element creation


> > Of course, this is assuming that all Element properties
> > can be set in JavaBean style, and don't have to be passed in the
> > constructor
>
> Problem here is that's not the case, since we explicitly have no-arg
> constructors "protected" so that users can't create non-well-formed
> items, like elements without specified names.  Special casing to pass a
> name is an option, but not a good one for the long term.

OK, point taken.  Well, my second choice is then making it easy and obvious
how to subclass SAXBuilder.  My experience has been that its easier to allow
"plug-in" extensions than to explicitly subclass library APIs (the fragile
subclass problem, etc.)  It would also allow the same plugin to be used for
all builders, not just SAXBuilder.

Design:

SAXBuilder:

1. Look for each "new Element" statement in SAXBuilder and replace with
"elementFactory.createElement( args)" for each element constructor in use.
Note that this factory doesn't have to handle ALL POSSIBLE constructors,
cause its for internal builder use.  This keeps it from getting fragile as
the API evolves.

2. Add a setElementFactory( ElementFactory factory) method.  By default,
this could even be SAXBuilder itself, implementing the ElementFactory
interface.

3. Users looking to provide custom Element implementations could define:

class MyFactory implements ElementFactory {
    public Element create( String name) {..}
    public Element create( String name, String namespace) {...}
    ...
}

and say:

SAXBuilder b = new SAXBuilder();
b.setElementFactory( new MyFactory());
b.build (reader);

This interface only needs to handle the internal SAXBuilder cases, not all
"convenience" constructor cases.