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的步骤为： 
在Digester初始化部分，指明要考虑命名空间。 
digester.setNamespaceAware(true);

指明一些规则的命名空间,如 
digester.setRuleNamespaceURI("http://www.mycompany.com/MyNamespace");

接下来定义一些与此命名空间有关的规则，此时可以省却前缀，如 
digester.addObjectCreate("foo/bar", "com.mycompany.MyFoo");
digester.addSetProperties("foo/bar");

对其它命名空间，重复前面的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考虑命名空间之后，如果不会引起歧义，完全可以忽略命名空间的存在，除非你要针对特定的命名空间进行特定的处理。