[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
> Sent: 03 January 2002 15:18
> To: xml-dev
> Subject: [xml-dev] Effective DOM (was RE: [xml-dev] 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.
|
