代码改变世界

WebWork深度探索之Pitfall

2004-08-25 14:31  FantasySoft  阅读(...)  评论(...编辑  收藏

        在使用WebWork进行开发的过程中,她的种种特性:简约为先的设计原则,IOC的实现,Interceptor的使用,Command模式的使用,利用OGNL作为其Expression Language,完备的类型转换,简便的配置以及完备的Validation都深深打动了我,让我将其列为开发Web  Application的第一framework。然而,金无足赤,强大的背后却有着或多或少的pitfall。
        首先,作为一个框架本身,它提供的文档还是不够充分的,sample也比较匮乏,而且文档中也存在与范例不一致
的地方,使得学习WebWork的曲线没有想象中的那么平滑。还记得有篇文章在比较框架之间优劣的时候,文档因素是被列在第一位的。因此,增加足够充分的文档与sample,是WebWork社区的当务之急了。
        其次,也许是与Velocity紧密结合的缘故,因此WebWork在表示层做得并不好。譬如她提供的Tag Library,除了
与ValueStack相关的几个标签具有一定的实用价值之外,其它的tag都让人觉得鸡肋的感觉。其实将页面上的UI元素封装成tag是一个不错的选择,但是WebWork的UI Tag做得并不出色。举个例子,<webwork:textfield>标签封装了<input type="text">,然而我却没有办法象使用<input>那样使用<webwork:textfield>,最重要的就是没有办法将CSS样式应用到她上面,如果加上class的属性的时候,tag在parse的时候就会报错。正是因为这个,我不得不弃用所有的UI标签。我想在UI上面,还得向ASP.NET多学习了。
        第三,虽然Validation框架提供了通过配置actionName-validation.xml的文件即可完成字段校验的大部分工作,但是如果某些字段的校验需要涉及数据库的查询,那么这样的方式不适用了。在类ActionSupport中定义了两个方法:addFiledError和addActionError,两者对应的参数的区别在于前者除了error message之外还需要一个参数就是field name,而后者就只有error message了。从这两个方法我们可以看出框架定义了两种层面上的错误,一种是Field级别的错误,一种是Acition级别的错误,那么我们应该将涉及数据库查询的字段级别的校验归为哪一类呢?其实,我个人认为这样的接口设计并不是最优的。首先action级别的错误也可能是由于字段不符合要求导致的,但是这样的校验需要数据库查询的支持,因此,我更加愿意让addActionError也带上field name的参数。其次,两种层面上的错误是可以统一起来的:       

addValidateError(ArrayList fieldNameList, String errorMessage);
addValidateError(String fieldName, String errorMessage);
addValidateError(String errorMessage);
               (注:方法的第一种形式是针对错误由几个字段共同引起的情况)      

        综合起来而言,我会选择将Validation写在每个action中,这样会让Validation更加集中,使用了配置文件就不可避免地将Validation分散在各处了。如果你担心代码的重复的问题,完全可以将类似的校验归并到一个Util类中,供所有的Action调用。