XObjects

[Bill la Forge]

From: Tyler Baker <tyler at infinet.com>
>(1) There is a root element handler that is passed to the parser which
handles
>all of the events generated by parsing the root element.  If a new child
element
>of the root element is encountered, the root element is responsible for
>instantiating an element handler for the given element name.  If no element
>handler can be instantiated then null is returned.
>
>(2) All of the generic events of SAX you could consider are delegated down
to
>the currently selected parent element which is receiving character,
element, and
>pi events among others.  This is done natively in my parser and has nothing
to
>do with SAX per se, but this sort of framework can be easily built on top
of SAX
>in a few hours I would think.  I personally have had a lot of success using
this
>method (I will admit my opinion is biased by my own personal adulation) and
find
>it to be just about as straightforward as using Java Object Serialization
as a
>framework for reading and writing object state.
>
>(3) No registry, bindings, or any other muckety muck is necessary.  All you
need
>is an instantiated implementation for a root element which knows how to
>instantiate children elements who know how to instantiate children elements
and
>so on and so forth.  It is equivalent to calling readObject() in Java
Object
>Serialization where you need to know the root object type to case to, but
you
>don't have to worry about the types of any of the child objects as the root
>object knows what types they need to be cast to.


As a component programmer (distinct from an oo programmer), I attempt to
avoid
embeding in a component class any knowledge of other component classes.
(A component may know about interfaces and objects, but not other
components.)
The last thing I want is to have components created by other components
using
the new operator.

Coins supports this programming style--all you need is a binding for the
smart root.
My own programming style depends on either factories or (preferably)
binderies.

Shouldn't XObject be able to accomodate diverse styles as well?
OK, it means moving closer to the SAX DocumentHandler interface than what I
had proposed. We need a START-ELEMENT to accomodate this.

But then we've constrained the implementation. Tough choice. Perhaps a DOM-
specific set of arguments on that START-ELEMENT would be a good compromise:

        public void startElement(
                    java.lang.String name,
                    org.w3c.dom.NamedNodeMap,
                    org.xml.sax.Location)
            throws SAXException;

This again allow for greater integration with the DOM without either
precluding or excluding the use of SAX.

Bill



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)