Java Chinese Document Object model DOM usage experience

The Document Object Model (DOM) is a document standard, and Dom provides a great deal of flexibility for complete documentation and complex applications. The DOM standard is standard. It is strong and complete, and has many implementations. This is the deciding factor for many large installations-especially for product applications-to avoid a lot of rewriting when the API changes.

These are the reasons why I chose not to choose Jdom or dom4j other object-oriented criteria when I was working on XML data. But also because DOM is a language-independent model from the outset, and it tends to be used in languages like C or Perl, without taking advantage of Java's object-oriented performance, So in the use of the process has also encountered a lot of trouble, today here to do a summary. In addition, I currently use XML mainly as a data transmission of the unified format, and unified user interface to show the interface, the application is not very wide, so the use of the DOM content is not much.

When you're ready to use it, it is well prepared and difficult to prepare, so there is a simple tool class to encapsulate the common methods necessary for DOM objects to be used, and it is actually very sensible to do so, a simple operation to create a Document object, If you need to write more than 5 lines of code each time, and still have to deal with those annoying exception, it will be a blow to everyone's enthusiasm, so in the beginning, did a Xmltool class, specifically encapsulated the following public methods:

1. Document object creation (including an empty document object creation, created as a root node with a given node node).

2. Converts a canonical XML string into a Document object.

3. Read an XML file from the physical hard disk and return a Document object.

4. Converts a Node object to a string.

Each of these methods intercepts the exception thrown by the associated DOM operation and transforms it into a runtimeexception throw, which, in the actual use, is not actually thrown in the normal state. Especially when generating a Document object, the Parserconfigurationexception, When converting node nodes into strings to generate a transformer object transformerconfigurationexception and so on, there's no need to spend time and energy on them. And really out of the relevant exception, in fact, there is no way to deal with, such a situation is usually the system environment configuration problems (such as the necessary DOM implementation parser, such as the package does not join the environment), so wrapped the exception is only very briefly get its message thrown.