Gee*_*Jan 10 validation json dry
作为广泛的测试用例的一部分,我正在构建一个基于ajax的类似CMS的应用程序,它在各种文档类型上提供CRUD功能,例如:文章,标签等.
在服务器端和客户端,我正在考虑使用JSON-schema(http://json-schema.org/)作为以干燥方式进行用户输入验证的方式(即:1验证模式,是在服务器端和客户端使用,没有重复代码和所有这些).这看起来很棒,因为:
JSON-schema都是用JS和Java实现的,因此理论上一个模式可以处理客户端和服务器端验证
所有CUD操作请求和响应都是JSON(通过ajax)
然而,除了用户输入的常规验证之外,我还希望在服务器上进行一些额外的检查(例如:检查用户想要创建的Tag的名称是否已经存在)
理想情况下,我希望这些类型的检查包含在我的一般服务器端验证代码中(如上所述,它将基于JSON模式).但是,我并不完全相信这是正确的方法,因为这些额外的检查不仅仅基于提供的JSON数据,而是需要额外的数据来验证(例如:系统中现有标签的名称,以检查是否标签名已经存在).
那么,在服务器端的基于json模式的验证框架中加入如上所述的附加检查是否是一个好主意(设计/架构明智)?这会是一个优雅的解决方案吗?或者你会完全分开吗?如果没有,为什么不这样做,你会建议在客户端和服务器端验证方面保持DRY吗?
你怎么看?
一些背景信息下面的文本案例的一些额外的上下文/目标.
谢谢,Geert-Jan
一些背景/目标:
基于ajax的CMS使用REST方法
CUD请求通过ajax使用rest方法执行(即:分别在POST,PUT,DELETE上映射).请求和响应都是通过JSON完成的.
没有表格的CMS.而是使用就地编辑(例如使用Aloha编辑器:http://www.aloha-editor.org/
保持干燥.
模板化:通过客户端和服务器端的Mustache模板完成.通过ajax进行初始渲染和增量渲染是基于1和相同的模板完成的.我想寻找与Mustache不同的东西(bc.它缺乏表现力),但它至少适用于这个原型.(请参阅上一个替代方案的问题,我仍在寻找答案:使用java编译器的客户端模板语言(DRY模板))
DRY输入验证:如上所述
验证流程(如果失败):
用户创建/更新/删除项目.
客户端上的验证失败会立即向用户反馈修复内容.(Javascript JSON-schema-validator理想情况下会返回格式化为用户的JSON)
当客户端验证成功时,使用ajax执行CUD操作.
如果服务器端验证失败,则返回状态代码400(错误请求),其中包含由jquery的错误回调拾取的验证失败的Json对象
$.ajax({
....
error: function(xhr, status, error) {
var validationJSON = JSON.parse(xhr.responseText);
//handle server-side validation failure
},
....
});
Run Code Online (Sandbox Code Playgroud)包含服务器端验证失败的JSON对象呈现给用户(类似于客户端)
在服务器上的一个位置(每个模型)拥有单一的验证定义是很有可能的,也是最令人高兴的事情之一,然后可以为客户端和基于 AJAX 的验证生成适当的 JS。
\n\nPHP 的 Yii 框架有一个奇妙的架构,可以以一种优雅的方式实现这一点,将所有验证规则一起存储在模型中(根据需要划分为适当的“场景”)。从这里开始,只需翻转几个开关即可使特定表单可在客户端或 AJAX 验证。我相信 Yii 的接口是基于 Rails 的。
\n\n无论如何,我强烈建议您查看 Yii 设计中的以下要点;即使您不懂 PHP,您也可以从中获得灵感:
\n\nCModel::rules()
=> 模型验证规则的 DRY 源CActiveForm
=> 用于根据模型属性生成表单元素\nCActiveForm::textField()
CValidator
=> 验证器的基类,提供客户端验证的能力我认为追求 DRY 验证规则声明是明智的,根据我的经验,实现 100% 并且仍然拥有丰富的表单 xe2x80x94 和丰富的验证规则并不是不现实的。(当你不必管理所有客户端验证 JS 时,你会热爱生活吗?)
\n\n希望这可以帮助。
\n 归档时间: |
|
查看次数: |
2322 次 |
最近记录: |