Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XObjects
I apologise if anyone gets this twice, I have a problem with my mail
currently.
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@d...
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
