Cart
[Home] [By Thread] [By Date] [Recent Entries]
Hi Jim, I've had a look at the great work you did with Xybrix. I ran it, played a little bit with the samples and had a look at your APIs. That's pretty impressive, and your point about why you don't currently support W3C XForm is pretty interesting. I notice that you had implemented your own abstraction layer for XML Parsers (the org.jbrix.xml.XMLDriver class or interface), and implemented it for Xerces. You should have a look at JAXP, because it is becoming more and more supported by implementors of XML Parsers and used by applications, so that you would save a lot of time by supporting JAXP instead of your own abstraction layer. The first step towards JAXP adoption could simply be to implement a JAXPXMLDriver, and voilà, you would have immediate support for dozens (well, maybe only half-dozens) of XML Parsers. The current XMLDriver solution is sad for me, because I don't use Xerces in my applications, but another parser through JAXP, which means i'm supposed to load the two parsers (and no, I don't want to use Xerces, for performance reasons) ! I'm telling you that because we did exactly the same thing : develop our own XML parser asbtraction layer (now deprecated by JAXP 1.0), our own XML transformation abstraction layer (now deprecated by TRAX and JAXP 1.1), and our own XPath expression evaluator abstraction layer (now somewhat deprecated by Jaxen)... It's the inconvenience of doing things too early :P. Concerning the fact that you don't want to be dependent of a particular DOM API (be it W3C DOM, JDOM or dom4j), you could use the Navigator option, as in Jaxen or Saxpath. This is the least intrusive method. Your second option is not as practical as the first one for people using your API, because people can't always guarantee that the DOMs they want to feed into your API have been built using your factory, and therefore you won't obtain the expected subclasses. Plus, you have to build subclasses of non-official classes (i.e. public classes that are marked as "should not be directly used unless you know what you are doing"), which means that your subclasses evolution rate will be bound to the evolution rate of the main product. You certainly don't want to maintain as much different subclasses version than there are versions in Xerces, even if evolutions in the Xerces classes will rarely break your own subclasses. The third method, "wrapper classes", is in fact close to the first one, instead that the first method features a navigation-oriented API rather than the tree-oriented API featured in method three. The difference between the two orientations may be rather slim, but that's not the point here. The point is that because you don't want to choose a reference DOM, you are building your own. This is crazy ! Why don't you choose a reference DOM between W3C DOM, JDOM and dom4j, then build either wrappers or bridges for others DOMs ? Plus, JDOM and dom4j do already have wrappers for the W3C DOM, and it's a matter of time before they feature JDOM wrappers for dom4j and vice versa ! So if you want to have a DOM neutral *navigation* API, you can write your own, or even reuse the Jaxen one. But if you want a tree-oriented API, make your choice between W3C DOM, JDOM and dom4j, and use wrappers. But DON'T build your own set of DOM interfaces ! Regards, Nicolas Lehuen Head of R&D - Ubicco http://www.ubicco.com/ ----- Original Message ----- From: "Jim Wissner" <jim@j...> To: <xml-dev@l...> Sent: Saturday, November 17, 2001 6:34 AM Subject: Achieving object model independence > > Hi, > > I would like to solicit the list's opinion about the best way to achieve > object model independence in a library that makes use of XML at a higher > application level. Specifically, I have a Swing-based implementation of > xforms, and it is currently based on DOM (Xerces). I would like to change > it so that it will work not only with Xerces, but with dom4j, JDOM, or any > other object model. > > There are three possibilities I'm currently looking at: > > 1. Build a Navigator similar to that in use by Jaxen/Saxpath, only mutable, > and pass that around instead of documents/elements/attributes/etc. > > 2. Create my own set of basic interfaces that mirror common object model > components (Document, Element, Attribute), subclass the implementation > classes of the corresponding dom4j/JDOM/DOM classes, set the appropriate > factory methods to create instances of the subclasses that implement my > common interfaces, and return those common interfaces to the rest of my > library. > > I currently use this method with Xerces in order to implement undo/redo of > DOM mutations, and it is quite effective. Nevertheless this approach makes > me uneasy because it is dependent on utilizing "nonpublic" components (that > is, having to subclass the default implementation classes which, though > often public in the sense of Java scoping, are sometimes left out of > documentation and presumably more subject to change than the rest of the > APIs. Is this true, or am I being overly worrisome?) > > 3. Similar to 2 in that I create my own set of basic interfaces that mirror > common object model components, but instead of the subclass/factory scheme, > make wrappers around the implementation classes of the corresponding > dom4j/JDOM/DOM classes, and again return those common interfaces to the > rest of my library. > > My questions are: > > 1. Is there a better method that I'm overlooking? > > 2. How are other people tackling the problem of object model independence > in cases where higher level libraries might be used in different contexts > with different object models? > > I would very much appreciate any expert advice and insights into this > problem, and how it can be best approached, and maybe hearing that this is > an easily (and perhaps already solved) problem... :) > > Many thanks in advance, > Jim > > > -- > www.jbrix.org > Open Source Software > Java - XML - Speech Recognition > > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > initiative of OASIS <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://lists.xml.org/ob/adm.pl> >
|
