再说Apache Commons Validator的不足

上次提到Commons Validator在校验Email地址的时候客户端逻辑和服务器端逻辑不一致。最近发现在Date校验以及Indexed Properties校验方面也有同样的问题。

Validator的服务器端Java代码可以支持完整的日期时间格式,例如(yyyy-MM-dd HH:mm:ss.S,由DateFormat类提供支持),但是在客户端的JavaScript代码里面只能支持日期本身,时间不被支持,例如(yyyy-MM-dd),观察客户端代码可以发现。

对于Indexed Properties(索引属性或曰集合属性),Validator可以在服务器端支持,但是在客户端同样无法支持。

这样的现状让我感到很困惑,这意味着Validator的实用性大打折扣--尽管它已经非常优秀。对一个B/S结构的软件来说,功能的多寡不是问题,而逻辑(B/S两端)不一致却是一个不能回避的原则性问题。尽管我们可以说,“客户端校验的不足,可以用服务器端的校验来补足”,但是这不是折衷,而是对软件设计的破坏。

犹豫着,要不要舍弃Commons Validator,似乎Apache本身,也不打算再对它进行更新,目前的最新版本是V1.3.1,但已经是1年以前的东西了。似乎它唯一的优势已经仅仅是在与Struts无缝集成、共享ApplicationResources以及其它资源方面了。如果不考虑多语言支持的话,用Commons Validator还有价值吗?

其实,针对以上的不足以及其它一些本文未提及的不足,许多热心的技术人员已经提供了比较可靠的解决方案,但是我不知道为什么Apache至今不采纳那些方案。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值