Digester学习笔记(三)转载

总觉得，Digester不仅仅能作配置文件解析，而且可以作得更多。

 

配置属性

　　Digester用来解析应用系统的配置文件，其本身也有很可配置的属性。

属性	描述
classLoader	指定类装载器(class loader)。ObjectCreateRule 和 FactoryCreateRule两个规则中，需要动态加载一些类（如那些盛放XML解析出来的数据的javaBean等），装载器可以在次指定。如果不指定，对这此类的加载将会利用线程上下文中的加载器（当useContextClassLoader值为真时）或利用加载Digester的那个加载器。
errorHandler	指定 SAX ErrorHandler，以在出现此类错误时调用。默认情况下，任何解析错误都会被记入日志，Digest会继续进行解析。
namespaceAware	一个布尔值，为真时对XML文件的解析时会考虑元素的域名空间（如不同的域名空间的同名元素会视为不同的元素）
ruleNamespaceURI	指定后续加入的规则所属的命名空间，如果此值为null,则加入的规则不与任何命名空间相联系。
rules	设定规则模板与XML元素的匹配处理程序。由于这个匹配程序是插件式的，所以匹配工作的完成可以用用户定义的匹配程序未完成。默认情况下，使用Digester提供的匹配器。
useContextClassLoader	一个布尔值，为真时FactoryCreateRule 和 ObjectCreateRule 两个规则中对类的装载将会采用当前线程上下文中指定的加载器。默认情况下，对类的动态加载会利用加载Digester的那个装载器。
validating	一个布尔值，为真时解析器会根据DTD内容对XML文档进行合法性检查，默认值是假，解析器只是检查XML是否格式良好(well formed).

　　除了上述属性外，还可以注册一个本地DTD，以供DOCTYPE声明引用。这样的注册告诉XML解析器，当遇到DOCTYPE声明时，应使用刚注册的DTD的内容，而不是DOCTYPE声明中的标识符(identifier)。
　　例如，Struect框架控制器中，使用下述的注册，告诉Structs使用一个本地的DTD中的相关内容来处理Structs配置文件，这样可以适用于那些没有连接到互联网的应用环境，而在连到互联网的环境中可以加快运行速度(因为它避免了通过网络去取相关的资源)。

URL url = new URL("/org/apache/struts/resources/struts-config_1_0.dtd");
digester.register("-//Apache Software Foundation//DTD Struts Configuration 1.0//EN",url.toString());

规则集打包

　　通常情况下，一个规则被创建后，接着便注册，然后等在event时被调用，这些规则集很难为其它应用程序直接复用。一个解决方法是将所有规则都放在一个类中，此由这些规则可以很简单地被装载然后被注册使用。RuleSet接口就是为些而设计，一般是通过扩展RuleSetBase类来开发规则集类。如例：

public class MyRuleSet extends RuleSetBase {
  public MyRuleSet() {
    this("");
  }
  public MyRuleSet(String prefix) {
    super();
    this.prefix = prefix;
    this.namespaceURI = "http://www.mycompany.com/MyNamespace";
  }
  protected String prefix = null;
  public void addRuleInstances(Digester digester) {
    digester.addObjectCreate(prefix + "foo/bar",
      "com.mycompany.MyFoo");
    digester.addSetProperties(prefix + "foo/bar");
  }
}

可以这样使用这个规则集

Digester digester = new Digester();
... 一些配置Digester ...
digester.addRuleSet(new MyRuleSet("baz/"));

带命名空间的XML解析

　　这种情况下，使用Digester的步骤为：

1. 在Digester初始化部分，指明要考虑命名空间。
   digester.setNamespaceAware(true);
2. 指明一些规则的命名空间,如
   digester.setRuleNamespaceURI("http://www.mycompany.com/MyNamespace");
3. 接下来定义一些与此命名空间有关的规则，此时可以省却前缀，如
   digester.addObjectCreate("foo/bar", "com.mycompany.MyFoo");
   digester.addSetProperties("foo/bar");
4. 对其它命名空间，重复前面的2步

　　另外，在指明要digester考虑命名空间之后，在定义匹配模板时，可以将命名空间别名加“：”作为元素名称的一部分使用。这与无命名空间时是一致的。

开发定制的匹配处理过程

　　通过实现 org.apache.commons.digester.Rules接口或扩展org.apache.commons.digester.RulesBase类来达到定制匹配过程的目的。
　　Digester提供ExtendedBaseRules来扩展了匹配模板的定义，引入了特殊通配字符?和＊以及!,提供RegexRules来支持以正则式的语法定义匹配模板，提供WithDefaultsRulesWrapper来支持默认规则（即其它规则都不匹配时的处理规则）。

一些认识

　　通过看说明材料，尤其在学习Digester包中的Catalog例子以后，有一些认识：
　　1、由于xml对属性名字的定义要求，与Java中对方法名字的定义要求不一致，导致出现不能自动映射的情况，如year-made标签属性，就不可能有方法setYear-made;
　　2、对于根元素，与其子元素建立联系，有几种办法：一种是先生成根元素实例，压入栈，然后解析，将调用方法规则建立联系；另一种是解析的过程中第一个创建它，然后用getRoot的方法得到。
　　3、如果某对象类构造都要参数，则此时需要扩展AbstractObjectCreationFactory类为这种对象建立一个Factory,在这个Factory中取得初始化参数值然后再创建一个对象实例。
　　4、设有某个标签，要想自动用该标签子元素的内容填充该标签对应的对象的属性，则需要用digester.setRules(new ExtendedBaseRules()),然后addRules(),然后再调用addBeanPropertySetter("bala/lala/?");进行规则定义,注意此模板中有通配符。
　　5、如果对象的属性是整型，则Digester自动将xml文件中字符串值转换为整型。
　　6、在指明要digester考虑命名空间之后，如果不会引起歧义，完全可以忽略命名空间的存在，除非你要针对特定的命名空间进行特定的处理。