xml-dev - Re: XObjects

[Tyler Baker <tyler@infinet.com>]

Graham Moore wrote:

> I think Tyler is right when he says that having access to the parser events
> is useful. While the SaxInput should remain in the domBuilder interface
> could one extension be something more raw.
>
>          build(URL xml); for example. The domBuilder can create its own
> parser set itself to be the event sink and build the DOM from the events.
>
> Tyler wrote >
>
> >The DOM is a general purpose tree for storing the parsed contents of an XML
> >stream.  I really don't like this subclassing idea very much though as the
> DOM
> >I believe is not suitable for this type of framework since you are no just
> >dealing with Element nodes but you are dealing with all kinds of nodes.
>
> Yes but at the end of the day a node is a node is a node. And isn't
> "is-a-kind-of" the time to use the inheritance pattern?
>
> I still prefer a delegation mechanism to a simple inheritance. More dynamic,
> more powerful.
>
> With delegation you could have a Node object, a functional object and a
> delegator object
>
> The functional and Node objects are added to the delegator object (mix them
> in). The delegator is then the reference to the composite functionality.
> There is no dependency between the functional and Node objects.
>
> >  I prefer a framework which says nothing about how the object tree is
> created or
> > even if there is an object tree.  The application should be responsible
> for
> > doing this...
>
> The application is responsible. Its the application that gives the
> domBuilder the construction rules / element bindings / delegation structures
> that it wants applied. And the app gets back a functional dom or set of
> objects.
>

I think you are all missing the point here about what I was talking about.  In
simple terms this is how it all works and it all has nothing to do with the DOM.

(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.

> > I think it would be a shame if this XOS API (or whatever it is named)
> favored
> > some registry based interface or mapping interface cause everyone has
> already
> > done these sort of things already for all kinds of applications and in the
> end
> > you usually find yourself in a configuration nightmare maintaining all of
> > these
> > mappings.
>
> Yes, but at some stage you need to know the functional object to build.
> Where in your example above do you find the class 'Height' is it local to
> the application package?, the domBuilder package?. There needs to be some
> mechanism for specifying the binding. I think that using the element name as
> a direct mapping into the current package will lead to problems further down
> the line.

This in Java is all Classloader specific.  Basically, when you have an object of
a particular type, the same classloader is used implicitly for instantiating all
of the child objects in the object graph unless a new class loader is
instantiated and used to define a particular class explicitly.  For my puposes I
use a PI at the beginning of the document which defines the class name of the
root element.  The way the core application works, I don't need to specify URL's
to Jar files (this is handled at a higher level) but this sort of thing could go
into a PI as well for executing this sort of dynamic action.  Last but not least,
an element name is merely a symbol that is used for each element to locate and
possibly instantiate an appropriate handler for that element type.  Using some
namespaces mechanism (the first namespaces draft worked great but the current
draft really makes this namespaces issue unnecessarily complicated) you can
further differentiate element types based on the URI of the namespace.

I will try and get a basic implementation of what I am talking about whipped up
by next week.  Right now I am swamped with other work and have no time to
dedicate to projects like these )-:

Regards,

Tyler



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