I think Tyler is right when he says that having access to the parser events=
=20
is useful=2E While the SaxInput should remain in the domBuilder interface=20
could one extension be something more raw=2E
build(URL xml); for example=2E The domBuilder can create its own=20
parser set itself to be the event sink and build the DOM from the events=2E
Tyler wrote >
>The DOM is a general purpose tree for storing the parsed contents of an XM=
L
>stream=2E I really don't like this subclassing idea very much though as t=
he=20
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=2E
Yes but at the end of the day a node is a node is a node=2E And isn't=20
"is-a-kind-of" the time to use the inheritance pattern?
I still prefer a delegation mechanism to a simple inheritance=2E More dynam=
ic,=20
more powerful=2E
With delegation you could have a Node object, a functional object and a=20
delegator object
The functional and Node objects are added to the delegator object (mix them=
=20
in)=2E The delegator is then the reference to the composite functionality=2E=
=20
There is no dependency between the functional and Node objects=2E
> I prefer a framework which says nothing about how the object tree is=20
created or
> even if there is an object tree=2E The application should be responsible=
=20
for
> doing this=2E=2E=2E
The application is responsible=2E Its the application that gives the=20
domBuilder the construction rules / element bindings / delegation structure=
s=20
that it wants applied=2E And the app gets back a functional dom or set of=20
objects=2E
> So if I have a rectangle object that has 4 possible children, x, y, width=
,=20
and
> height the code for implementing the forElementName method would be=20
something
> like:
> public Element forElementName(String name, int index) {
> if (name =3D=3D "x") {
> this=2Ex =3D new X();
> return x;
> }
> else if (name =3D=3D "y") {
> this=2Ey =3D new Y();
> return y;
> }
> else if (name =3D=3D "width") {
> this=2Ewidth =3D new Width();
> return width;
> }
> else if (name =3D=3D "height") {
> this=2Eheight =3D new Height();
> return height;
> }
> return null;
>}
> where objects X, Y, Width, and Height implement the element interface as=20
well=2E
> Of course it would make much more sense to treat all of these as=20
attributes
> here, but I am just using this as an example=2E
The generic form of this is=2E=2E=2E=2E
public gdo createFunctionalXMLObject(gdo parent, String className){
gdo result=3D null;
try {
Class c =3D Class=2EforName(PACKAGE + "=2E " + className);
Constructor cons =3D c=2EgetConstructors()[0];
result =3D (gdo)cons=2EnewInstance(null);
result=2Einit(parent,elemName);
} catch (Exception e){
System=2Eout=2Eprintln("Class creation error : " + e);
}
return result;
}
Where PACKAGE is the java package name=2E
I think this is pretty much the way the SUN ea stuff works already=2E
Assumptions here are that
a) the functional class subclasses from gdo (generic data object) / Node=2E
b) there is a default constructor that takes no arguments=2E
Comparing the two examples : for every application where you need=20
functionality attached to XML objects
In the generic scenerio the application writer merely specifies the binding=
s=20
and writes ONLY the new functional class, if a new one needs to be written=2E=
=20
This means they dont have to write the builder or implement the DOM node=20
methods=2E
Notice also how
in VB
set x =3D CreateObject(PACKAGE & "=2E" & className)
in C++
obj =3D CoCreateInstance(PACKAGE + "=2E" + className);
and in python
x =3D OleCreate(PACKAGE + "=2E" + className) - I can't remember the functio=
n=20
call but its something like that=2E Paul knows=2E
Would work=2E
In addition I think the thing to remember is that someone has structured th=
e=20
XML as it is for a reason=2E If there is no interest in maintiaining the=20
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=20
builds from the XML=2E If there is no mapping then you get the generic data=
=20
object=2E
> I think it would be a shame if this XOS API (or whatever it is named)=20
favored
> some registry based interface or mapping interface cause everyone has=20
already
> done these sort of things already for all kinds of applications and in th=
e=20
end
> you usually find yourself in a configuration nightmare maintaining all of
> these
> mappings=2E
Yes, but at some stage you need to know the functional object to build=2E=20
Where in your example above do you find the class 'Height' is it local to=20
the application package?, the domBuilder package?=2E There needs to be some=
=20
mechanism for specifying the binding=2E I think that using the element name=
as=20
a direct mapping into the current package will lead to problems further dow=
n=20
the line=2E
graham=2E
gdm@dpsl=2Eco=2Euk