[AppFuse] AppFuse使用手记－Validator（八）

1. [AppFuse] AppFuse使用手记－－安装（一）[原]
   
2. [AppFuse] AppFuse使用手记－－试例（二）[原]
   
3. [AppFuse] AppFuse使用手记－－目录结构（三）[原]
   
4. [AppFuse] AppFuse使用手记－－数据库中文问题（四）[原]
   
5. [AppFuse] AppFuse使用手记－－资源文件中文问题（五）[原]
   
6. [AppFuse] AppFuse使用手记－－一对多（六）[原]
   
7. [AppFuse] AppFuse使用手记－－DAO（七）[原]
   
8. [AppFuse] AppFuse使用手记－－Validator（八）[原]
   
9. [AppFuse] AppFuse使用手记－－Display Tag 分页（九）[原]
   
10. [AppFuse] AppFuse使用手记－－DWR（十）[原]
    

上篇中例子还有一个小小的问题。因为所有的Action配置都指向同一个Action类。而AppFuse会对没敢Action生成一个Validator的xml文件。而当同一个Action里包含很多操作，而这些操作对同一个POJO效验又不一样时，就会出现问题。比较常见的时，一个POJO Create和Update时对某个field效验不能为空，而POJO做为查询条件时这个field却允许为空。这样生成的Validator配置就不能同时运用于这一个Action。

而Validator的配置文件为ActionName-validation.xml，即每个xml对应于一个Action。所以需要我们把不同的操作放到不同的Action里，在配置不同的xml验规则。这样有一个问题，就是可能引起Action的类爆炸，而且不同的Action里可能会有很多相同的代码。我但是想能不能用Action的extends来避免这个问题。后来发现Action的extends是可以规避类爆炸的问题，可是效验还是会出现向前的问题，原因是因为“WebWork搜索活动类的继承树寻找父类或接口的校验规则”。就是说，验框架按照自上而下的顺序在类层次查找配置文件。

还有一种解决的方法，就是自己写一个Validator，可以参考结合 验证在struts中减少Action和ActionForm的数量。

我建议WebWork可以考虑在Validator的效验规则里象struts.xml的Action标签一样增加method参数。可以根据不同的method定义不同的效验规则。

转载于:https://www.cnblogs.com/vanuan/archive/2008/04/27/9576004.html