xml-dev - Re: SAX and stuff ...

[Jack Rusher <jar@integratus.com>]

Michael Brennan wrote:
> 
> more recently I switched to a different approach. I felt that this approach
> somewhat constrains extensibility. Each node that accepts children must be
> responsible for creating every possible type of child.

  This is only partially true.  If you use the DTD to control the
structure of the tree, and set up the ObjectFactory correctly, the only
files that are touched by adding additional objects are the
ObjectFactory and the file containing the new object definition.  The
parents need not know about the children, they just implement the
ObjectFactory's interface and delegate the actual creation to an object
knows how to make all of the objects in the application.

  You can further reduce this dependency by having the ObjectFactory
pick up all valid classes by pulling them in at run time.  If you do
that, you can write code that doesn't need to be changed at all when you
add new component types.  I have found this to be particularly useful.

> implementation). Then, I use a simple Hashtable (loaded from a Java
> Properties file) to map element names to a class that is loaded via
> reflection (just as Stefan Haustein noted in another post). The BaseHandler
> that is maintaining the stack of current ElementHandlers invokes "addChild"
> on the parent ElementHandler after instantiating a new ElementHandler.

  This is an excellent approach.  It uses Java's lovely reflection API
to do what I do with self descriptive loadable modules under C++.  The
addChild method is actually defined in the ParserListener
(ElementHandler) for me, too.

> This child, of course, needs to derive from a type that the parent knows how
> to deal with, but at least it can exploit polymorphism, here, and the parent
> need not be responsible for knowing every possible specialization that can
> be instantiated.

  My method for achieving this same functionality was to create a
BaseObject class that knows how to Do The Right Thing(tm) in a generic
sense.  All of the application specific sub classes only need to
overload that functionality when they have very special needs (I have
found this to be quite rare).

-- 
Jack Rusher, Senior Engineer | mailto:jar@integratus.com
Integratus, Inc.             | http://www.integratus.com