Christopher Elkins wrote:
>
> Comments inline.
>
> Scott Tavares [[EMAIL PROTECTED]] wrote:
> > Well here it is... what do ya think?
> >
> <...snip...>
> >
> > import org.apache.xerces.parsers.DOMParser;
> > import org.apache.xerces.dom.traversal.NodeIteratorImpl;
> > import org.apache.xerces.domx.traversal.*;
> > import org.apache.xerces.dom.DocumentImpl;
> > import org.apache.xerces.dom.NodeImpl;
> >
> I know Xerces is the preferred parser (because it's Apache and one of the few
> with any kind of XML Schema support), but we should probably stick to generic
> interfaces if at all possible.
Yup, absolutely. THe problem is that with DOM it isn't so simple... you
can have either:
<code>
DOMParser parser = new DOMParser();
parser.parse(uri);
Document doc = parser.getDocument()
</code>
which is the Xerces, IBMXML4J way,
or:
<code>
DOMParser parser = new DOMParser();
Document doc = parser.parse(uri);
</code>
which is the more traditional way (older IBM XML4J, I think OpenXML).
Again, another reason I think that SAX should be used, with an optional
DOM layer on top if desired. SAX gets rid of this with:
<code>
Parser parser = ParserFactory.makeParser(parserClassName);
parser.parse(uri);
</code>
DOM specifies how the document behaves, not the parser, while SAX
specifies the parser interface. Much desiraeable to at least have the
latter, and then the former as an option.
>
> > /**
> > * This class implements the DOM XML Paser from
> > * the Apache Xerces Project. This class also functions
> > * as its name implies... ClassMap factory for OPaL ClassMaps
> > * objects.
> > */
> > public class ClassMapFactory
> > {
> > private static ClassMapFactory instance;
> >
> I like this; it really should follow a factory pattern. And I agree with jon,
> it should probably be a service.
+1
>
> >
> > private ClassMapFactory(PersistenceBroker persistenceBroker)
> > {
> > this.persistenceBroker = persistenceBroker;
> > }
> >
> I don't have an answer to this, but I thought about it a lot when I was
> writing my implementation. Which is more OO-pure: having PersistenceBroker
> get ClassMaps from the factory and adding them to itself or having the
> factory mutate PersistenceBroker by adding ClassMaps to it?
The first. The factory design pattern states that a factory has _only_
one job - to produce objects. Nothing else.
>
> > /**
> > * This is the primary function of this class
> > * it takes a string that names the source
> > * XML File parses it and create the ClassMaps
> > * accordingly.
> > *
> > *<p>
> > * FIXME: Add an overloaded method that
> > * takes a URI (DynamicURI) as a
> > * parameter.
> > *<p>
> > * @param xmlFile a string with the name and location of an XML file.
> > *<p>
> > */
> > public void buildClassMaps(String xmlFile)
> > try{
> > parser = new DOMParser();
> >
> The parser to use should be set in the TurbineResources.properties.
+1
>
> >
> > /**
> > * Recursively process the node of an XML file
> > * and creates the matching classes and joins them
> > * together.
> > *
> > *@param iterator an NodeIteratorImpl from Xerces
> > *
> > */
> > private void processXMLNodes(NodeIteratorImpl iterator)
> > {
> <snip>
> > }
> >
> This basically does the same thing as my SAX implementation, just in the
> DOM way. I don't have enough expertise in this area to determine which way
> is better, although my gut tells me SAX. (Brett, oh resident XML expert,
> please insert comments <here>!)
How about <here />?
I think SAX is the way to go for this - I don't see the value of
carrying around a DOM tree. Yes, it's easier to use, but no, it's not
as portable in getting the DOM output, and it doesn't buy us anything in
this core level. However, I'm all for extensibility, and adding a DOM
layer that can be added/removed at will. Your gut is right, and it's a
harder solution to implement well, but a good one all the same ;-)
Keep in mind, you still use SAX either way - with DOM, to create the
DOM, with SAX, to get your callbacks. So eliminate the DOM
_requirement_, use SAX with callbacks, and then add DOM when
transformations need to occur and a DOM tree is needed as input for
XSLT.
-Brett
>
> Overall
> =======
> + Factory pattern is good, although should be service-based.
> - Less explicit refs to Xerces. Parser determined by config file.
> / DOM vs. SAX, the battle continues.
>
> --
> Christopher Elkins
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
