XObjects

[Graham Moore]

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.

> So if I have a rectangle object that has 4 possible children, x, y, width, 
and
> height the code for implementing the forElementName method would be 
something
> like:

> public Element forElementName(String name, int index) {
>   if (name == "x") {
>    this.x = new X();
>    return x;
>   }
>  else if (name == "y") {
>    this.y = new Y();
>    return y;
>  }
>  else if (name == "width") {
>    this.width = new Width();
>    return width;
>  }
>  else if (name == "height") {
>    this.height = new Height();
>    return height;
>  }
>  return null;
>}

> where objects X, Y, Width, and Height implement the element interface as 
well.
> Of course it would make much more sense to treat all of these as 
attributes
> here, but I am just using this as an example.

The generic form of this is....

public gdo createFunctionalXMLObject(gdo parent, String className){
    gdo result= null;
    try {
      Class c = Class.forName(PACKAGE + ". " + className);
      Constructor cons = c.getConstructors()[0];
      result = (gdo)cons.newInstance(null);
      result.init(parent,elemName);
    } catch (Exception e){
      System.out.println("Class creation error : " + e);
    }
    return result;
}

Where PACKAGE  is the java package name.

I think this is pretty much the way the SUN ea stuff works already.

Assumptions here are that

a) the functional class subclasses from gdo (generic data object) / Node.
b) there is a default constructor that takes no arguments.

Comparing the two examples : for every application where you need 
functionality attached to XML objects

In the generic scenerio the application writer merely specifies the bindings 
and writes ONLY the new functional class, if a new one needs to be written. 
This means they dont have to write the builder or implement the DOM node 
methods.

Notice also how

in VB
set x = CreateObject(PACKAGE & "." & className)

in C++
obj = CoCreateInstance(PACKAGE + "." + className);

and in python
x = OleCreate(PACKAGE + "." + className) - I can't remember the function 
call but its something like that. Paul knows.

Would work.


In addition I think the thing to remember is that someone has structured the 
XML as it is for a reason. If there is no interest in maintiaining the 
structure but a set of functional objects are required then either :

1) The xml is a single container with a flat list of children

or

2) The domBuilder is configured to return a collection of objects that it 
builds from the XML. If there is no mapping then you get the generic data 
object.

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

graham.

gdm at dpsl.co.uk





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)