改进后的表单验证架构

阅读更多

今天几乎花了一天的时间改进系统中的表单验证架构。对于一表单验证部分，我有两点最基本的思想：一是验证的Rules以XML定义的形式同HTML页面相互分离，便于开发和维护；二是对于不依赖后台数据的验证以前台的方式进行，必要时也有方便的接口可以同后台进行数据上的交互。

 

这两点，在从前的代码中基本上都已经实现了，现在做的工作基本就是对功能的增强。当前能够实现到什么样的功能呢？可以先看一下这个验证规则的定义文件应该会有一个大概的感觉：

 

首先应该可以很直观地看出来，Rule是可以嵌套的，而子节点的验证只会在父节点通过验证的情况下才会得以执行。这一点很重要，因为有些同后台交互的验证是比较耗资源的，运行时会有延迟的感觉，这种验证一定要在其它验证都通过时才去做。

 

unique是一个同后台交互的验证，会根据查询是否有结果来判断当前的值是否唯一。对于后台的验证，只要写一个Class实现Rule接口即可。

public interface Rule
{
	String check(Object v,Map ps) throws Exception;
}

 在验证规则的配置文件中，可以简单的写上这个类的Class，也可以稍加配置，用一个简单的名称来代替：

unique:"com.opesoft.pf.rules.UniqueRule"

 

可以看到，unique规则是被包含在一个标签中的。这里引入了和 标签，写在这个标签中的验证条件不会被显示到最终的出错信息中，只作为是否执行子验证的条件。上面的配置用这个标签实现了在Insert和Update情况下用不同的SQL来检验唯一性。

 

SQL语句中${code}这样的变量，在发送到后台前，会用表单中Code字段的值来填充，对于一些需要其它字段的值来辅助进行验证的条件，比如两个Passwrod中输入的密码是否一至，都可以用这种方式把另一个字段的值传进去。

 

对于验证结果的处理，别外写了一个FormWrapper的类。当前的方式是在前台的Label后面显示一个红色的叉号，鼠标移上去会显示出错的具体信息。因为这部分处理和Validate是分离的，所以很容易在以后扩展成不同的处理方式。

 

当然，当前的验证框架也有很多缺点，比如说就不支持现在比较流行的onchange后立即进行验证的方式，原因是考虑到因此可能会产生的复杂性及同表单完素的分离不可能做的非常好。不过我会努力的不断完善和改进它~