概述:
Jdom是用Java语言读、写、操作XML的新API函数。Jason Hunter 和 Brett McLaughlin公开发布了它的测试版本。在直觉、简单和高效的前提下,这些API函数被最大限度的优化。在接下来的篇幅里,Hunter 和 McLaughlin介绍怎么用Jdom去读写一个已经存在的XML文档。
Jdom是一个开源的api,它以直接易懂的方式向java程序员描述XML文档和文档的内容。就象名字揭示的那样,Jdom是为java优化的。为使用XML文档提供一个低消耗的方法。Jdom的使用者可以不必掌握太多的XML的知识就可以完成想要的操作。
Jdom可以和已有的XML技术如Simple API for XML (SAX)和 Document Object Model (DOM)相互协作.然而,它并不是简单的从这些api中提取出一些。Jdom从这些已存在的技术中吸收了好的方面,自己建立了一套新的类和接口,用一个Jdom用户的话来说就是:“这些接口是我从一开始阅读org.w3c.dom就期待的”;Jdom可以读入SAX或是DOM的内容,也可以输出SAX或DOM可以接收的格式。这个能力可以使Jdom很好的和已有的用SAX或DOM建立的系统之间整合。
Jdom的原则
第一条并且是最重要的一条就是Jdom的api函数被设计成对java程序员来说是简单易懂的。其他的XML解析函数被设计成语言通用的(支持相同的api函数在java,c++,甚至是javascript中)。Jdom利用了java的优秀的特征,如:方法重载、回收机制,和后台处理等。
为了能够简单易用,这些函数不得不以程序员喜欢的形式来描绘XML文档。例如:程序员想的到的一个元素的文本内容是什么样子的呢?
在一些api中,元素的文本内容仅被当作是一个元素的孩子节点。从技术角度来说,这个设计需要下面的代码才能访问到元素的内容:
Jdom用一种更简单易用的方法来取得元素的内容:
Jdom尽可能的减少程序员的工作量。依据拇指规则,Jdom应该用20%或是更少的努力来完成80%或是更多的java/xml方面的问题。这并不是说Jdom只是支持80%的XML规范(实际上我们希望Jdom100%的支持XML规范)。这个拇指规则是说有些东西可以加进去,但是没有必要。这些api函数应该保持简洁。
Jdom的第二条原则是说Jdom应该是快速的和轻量级的。调入和执行文档应该快速,内存的消耗应该尽量小。Jdom的设计明显是遵循这个原则。例如,就算在开始的时候,不太协调的操作已经比DOM快,但是比SAX显的粗糙。尽管这样,Jdom还是有许多SAX没有的优点。
你需要Jdom吗?
那么,你需要Jdom吗?这真是一个很好的问题。已经有了存在的标准,为什么还要去发明一个新的呢?答案是Jdom解决了现有的标准解决不了的问题。
DOM完全在内存中描述一个元素树。它是一个大的api,被设计操作几乎所有可能的XML任务。它也必须有相同的api去支持不同的语言。因为这些限制,对那些习惯使用java的特征,如方法重载、简单的set,get方法的java程序员来说,就很不习惯。DOM还需要大量的内存和较高的主频,这使它很难和许多轻量级的web应用一起工作。
SAX没有在内存中建立一个元素树,它用事情发展的方式来描述。例如:它报告每个读到的开始标记和结束标记。这种处理方式使它成为一个轻量级的快速读取的api。然而,这种事件处理方式对服务器端的java程序员来说不够直观。SAX也不支持修改XML文档和随机读取。
Jdom试图组合DOM和SAX的优点。它被设计成一个可以在小内存上快速执行轻量级api 。Jdom也支持随机读取整个文档,但是令人惊奇的是它并不需要把整个文档读到内存中。这个api支持未来的当需要时才读入信息的次轻量级操作。还有,Jdom通过标准的构造器和set方法支持XML文档的修改。
获取XML文档
Jdom用org.Jdom.Document类的一个实例来描述一个XML文档。这个文档类是一个轻重量级的,它可以包括文档类型、多处理指令的对象、一个根元素和注释对象。你可以不需要构造器而从草稿构造一个文档。
本文后面我们会讨论从草稿构造一个XML文档是多么的容易。但是现在,我们从一个已存在的文件、一个流、或是一个URL路径中构造我们的文档。
你可以用org.Jdom.input包中提供的构造类从任何数据源中构造文档。最近,有两种构造方式:SAXBuilder 和 DOMBuilder。SAXBuilder用sax解析器从文件中构造文档。SAXBuilder侦听sax事件并从内存中建立一个相应的文档。这种方式非常快(基本上和sax一样快),这也是我们推荐的方式。DOMBuilder是另一种可选的方式,它从一个存在的org.w3c.dom.Document对象中建立Jdom文档。它允许Jdom轻松的和构建DOM树的工具实现接口。
Jdom的速度有值得期待的提高的潜力通过一个延期的构造器的完成。这个构造器检查XML数据源,但当请求的时候才对它解析。例如:文档的属性当不访问时是不需要解析的。
构造器仍在发展,可以通sql查询、ldap查询和其他的数据格式来够造Jdom文档。所以,一旦进到内存中,文档就和建造它的工具没有关系了。
SAXBuilder 和 DOMBuilder构造器允许用户指明他们是否应该轮换,以便确定哪个解析器时间执行解析的任务。
默认的是用apache的开源 Xerces解析器并且是关闭轮换的。你应该注到DOMBuilder不象一个解析类,倒更象一个适配类。这是因为不是所有的DOM解析器都是相同的api。为了仍让用户选择喜欢的解析器,Jdom使用一个对所有的dom解析器适用的公共的api的适配类。这个适配类支持所有流行的dom解析器,包括Apache 的 Xerces, Crimson,IBM 的 XML4J, Sun 的 Project X, 和Oracle 的 parsers V1 and V2.每一个解析器通过正确的调用别的解析器的方法执行标准的接口。这有点象jaxp,除了它支持jaxp所不支持的新的解析器。
Jdom是用Java语言读、写、操作XML的新API函数。Jason Hunter 和 Brett McLaughlin公开发布了它的测试版本。在直觉、简单和高效的前提下,这些API函数被最大限度的优化。在接下来的篇幅里,Hunter 和 McLaughlin介绍怎么用Jdom去读写一个已经存在的XML文档。
Jdom是一个开源的api,它以直接易懂的方式向java程序员描述XML文档和文档的内容。就象名字揭示的那样,Jdom是为java优化的。为使用XML文档提供一个低消耗的方法。Jdom的使用者可以不必掌握太多的XML的知识就可以完成想要的操作。
Jdom可以和已有的XML技术如Simple API for XML (SAX)和 Document Object Model (DOM)相互协作.然而,它并不是简单的从这些api中提取出一些。Jdom从这些已存在的技术中吸收了好的方面,自己建立了一套新的类和接口,用一个Jdom用户的话来说就是:“这些接口是我从一开始阅读org.w3c.dom就期待的”;Jdom可以读入SAX或是DOM的内容,也可以输出SAX或DOM可以接收的格式。这个能力可以使Jdom很好的和已有的用SAX或DOM建立的系统之间整合。
Jdom的原则
第一条并且是最重要的一条就是Jdom的api函数被设计成对java程序员来说是简单易懂的。其他的XML解析函数被设计成语言通用的(支持相同的api函数在java,c++,甚至是javascript中)。Jdom利用了java的优秀的特征,如:方法重载、回收机制,和后台处理等。
为了能够简单易用,这些函数不得不以程序员喜欢的形式来描绘XML文档。例如:程序员想的到的一个元素的文本内容是什么样子的呢?
<element>This is my text content</element> |
在一些api中,元素的文本内容仅被当作是一个元素的孩子节点。从技术角度来说,这个设计需要下面的代码才能访问到元素的内容:
String content = element.getFirstChild().getValue(); |
Jdom用一种更简单易用的方法来取得元素的内容:
String text = element.getText(); |
Jdom尽可能的减少程序员的工作量。依据拇指规则,Jdom应该用20%或是更少的努力来完成80%或是更多的java/xml方面的问题。这并不是说Jdom只是支持80%的XML规范(实际上我们希望Jdom100%的支持XML规范)。这个拇指规则是说有些东西可以加进去,但是没有必要。这些api函数应该保持简洁。
Jdom的第二条原则是说Jdom应该是快速的和轻量级的。调入和执行文档应该快速,内存的消耗应该尽量小。Jdom的设计明显是遵循这个原则。例如,就算在开始的时候,不太协调的操作已经比DOM快,但是比SAX显的粗糙。尽管这样,Jdom还是有许多SAX没有的优点。
你需要Jdom吗?
那么,你需要Jdom吗?这真是一个很好的问题。已经有了存在的标准,为什么还要去发明一个新的呢?答案是Jdom解决了现有的标准解决不了的问题。
DOM完全在内存中描述一个元素树。它是一个大的api,被设计操作几乎所有可能的XML任务。它也必须有相同的api去支持不同的语言。因为这些限制,对那些习惯使用java的特征,如方法重载、简单的set,get方法的java程序员来说,就很不习惯。DOM还需要大量的内存和较高的主频,这使它很难和许多轻量级的web应用一起工作。
SAX没有在内存中建立一个元素树,它用事情发展的方式来描述。例如:它报告每个读到的开始标记和结束标记。这种处理方式使它成为一个轻量级的快速读取的api。然而,这种事件处理方式对服务器端的java程序员来说不够直观。SAX也不支持修改XML文档和随机读取。
Jdom试图组合DOM和SAX的优点。它被设计成一个可以在小内存上快速执行轻量级api 。Jdom也支持随机读取整个文档,但是令人惊奇的是它并不需要把整个文档读到内存中。这个api支持未来的当需要时才读入信息的次轻量级操作。还有,Jdom通过标准的构造器和set方法支持XML文档的修改。
获取XML文档
Jdom用org.Jdom.Document类的一个实例来描述一个XML文档。这个文档类是一个轻重量级的,它可以包括文档类型、多处理指令的对象、一个根元素和注释对象。你可以不需要构造器而从草稿构造一个文档。
Document doc = new Document(new Element("rootElement")); |
本文后面我们会讨论从草稿构造一个XML文档是多么的容易。但是现在,我们从一个已存在的文件、一个流、或是一个URL路径中构造我们的文档。
SAXBuilder builder = new SAXBuilder(); Document doc = builder.build(url); |
你可以用org.Jdom.input包中提供的构造类从任何数据源中构造文档。最近,有两种构造方式:SAXBuilder 和 DOMBuilder。SAXBuilder用sax解析器从文件中构造文档。SAXBuilder侦听sax事件并从内存中建立一个相应的文档。这种方式非常快(基本上和sax一样快),这也是我们推荐的方式。DOMBuilder是另一种可选的方式,它从一个存在的org.w3c.dom.Document对象中建立Jdom文档。它允许Jdom轻松的和构建DOM树的工具实现接口。
Jdom的速度有值得期待的提高的潜力通过一个延期的构造器的完成。这个构造器检查XML数据源,但当请求的时候才对它解析。例如:文档的属性当不访问时是不需要解析的。
构造器仍在发展,可以通sql查询、ldap查询和其他的数据格式来够造Jdom文档。所以,一旦进到内存中,文档就和建造它的工具没有关系了。
SAXBuilder 和 DOMBuilder构造器允许用户指明他们是否应该轮换,以便确定哪个解析器时间执行解析的任务。
public SAXBuilder(String parserClass, boolean validation); public DOMBuilder(String adapterClass, boolean validation); |
默认的是用apache的开源 Xerces解析器并且是关闭轮换的。你应该注到DOMBuilder不象一个解析类,倒更象一个适配类。这是因为不是所有的DOM解析器都是相同的api。为了仍让用户选择喜欢的解析器,Jdom使用一个对所有的dom解析器适用的公共的api的适配类。这个适配类支持所有流行的dom解析器,包括Apache 的 Xerces, Crimson,IBM 的 XML4J, Sun 的 Project X, 和Oracle 的 parsers V1 and V2.每一个解析器通过正确的调用别的解析器的方法执行标准的接口。这有点象jaxp,除了它支持jaxp所不支持的新的解析器。