Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Effective DOM (was RE: Effective XML)
 > -----Original Message----- > From: Champion, Mike [mailto:Mike.Champion@S...] > Sent: 03 January 2002 15:18 > To: xml-dev > Subject: Effective DOM (was RE: Effective XML) > > ...But in my biased opinion, it seems like a pretty straightforward way to use the > generic XML object model. It will be MORE useful when Level 3 defines > standard load/save, validation, and XPath access interfaces are defined, of > course. Yes these facilities will help, but it's unfortunate that they've been left until Level 3 -- they'd have saved a lot of heartache if they could have been dealt with earlier, IMO. > I'd be interested in hearing concrete examples of why people find the DOM > painful to use, in what ways JDOM and dom4j seem more friendly (besides > their native Java idioms, of course), etc. Well the native Java idioms cover a number of reasons why I like JDOM and dom4j. I completely understand why the DOM interfaces are language-neutral, and rightly so. However that's why I was suggesting (and Fred Drake seems to agree) that if the primary object model for your application is that of the XML document, then the DOM is the correct model. However if you're just importing/exporting XML data from an application then another API will probably be easier to work with. This seems to fit well within the design goals of the DOM. I'd also place this as slightly different decision to whether one should adopt a JAXB-like tool. I'd suggest these are useful if you're using XML data to drive the creation of the majority of your application objects. Slightly different than choosing a handly tree API to work with -- and as we've seen before this is often the model that beginners prefer to work with. >I have three motivations for soliciting this input: > > - Improving the standard DOM down the road > - Defining convenience layers on top of the W3C DOM that minimize the pain > - Defining and documenting DOM gotchas, workarounds, best practices, etc. IMO, the last two of these seem to have the most promise, mainly because I'm in favour of capturing best practices, but also because it was knuckling down to write a number of utility functions that ended up minimizing most of my pains. Are there any public collections of DOM utilities? This might be a useful thing to collect together if there isn't. My list of utilities includes: - document factory, and writers (obsolete with JAXP and DOM Level 3) - methods to convert nodes to text (e.g. getting text content from elements, etc) and simple Java types, e.g ints - getting the path for a given node - pruning elements, including shifting their children upwards in tree - pruning by name - moving children between elements - renaming elements - node copying utilities (for moving nodes between documents) - moving attributes into text content and vice verse - DOM searching (i.e. quering) using a simple XPath subset I also ended up implementing some of the DOM interfaces, e.g. DOMException, NodeList, NamedNodeMap to support some of these. The majority of these were for a scripted transformation engine I wrote in 1999. For this DOM was the right model, and besides there's wasn't anything else :) Cheers, L. 
|
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
|
|||||||||
