需要有关创建新"标准"/"语言"的建议

Question

更新:在评论中建议我为此创建一个wiki.我已经完成了,你可以在这里找到它(如果你想密切关注和/或贡献).

http://vrs.tomelders.com

我之前从未做过这样的事情,所以我完全放弃它.

---

我以前从来没有做过这样的事,所以请

我想要开放的"标准"或"语言",或者......好吧,我真的不知道该怎么称呼它......使表单验证更容易.我称之为VRS(验证规则表),但在这个阶段,一切都可以协商.

我们的想法是创建一张规则,类似于CSS,定义如何验证表单.这将需要

1. 语法/规范
2. 一个VRS解析器将VRS转换为可用的东西
3. 一个VRS处理器,用于将表单数据与规则进行比较并返回响应.
4. 响应格式.

像这样的系统的好处是

1. 用于定义表单验证的平台/语言无关的方法.
2. 一种跨平台,高度可移植的方式来定义表单验证.
3. 易于阅读,易于设置,易于修改.
4. 客户端和后端集成.

首先是第一件事.语法/规范应该是什么样的.

我在网上看到这种方式的方式是可以将VRS文件指定为隐藏字段,并且应用程序在处理之前将提供的表单数据通过VRS处理器进行路由.

举个例子,你可以验证"name"字段的内容类型是这样的

name {
    content-type: alpha;
}

content-type可以是以下三个值之一:alpha,numeric或alpha-numeric.

希望这是有道理的.我之前从未做过这样的事情所以我渴望得到别人的意见.就这一点而言,我已经到了

------------------------------------------------------------

content-type: (string) alphanumeric | alpha | numeric

Restricts content to either numeric, text or alphanumeric.

------------------------------------------------------------

is-fatal: BOOL

If the rule fails, is it fatal? This could be really useful
for AJAX responses.

------------------------------------------------------------

allow-null: BOOL

wether a field can be empty or not. Good for required fields
and checkboxes 

------------------------------------------------------------

pattern-match: (string) email | url | regex

match the field against a pattern. 

------------------------------------------------------------

field-match: (string) field_name

compares a field to another field. eg: password confirmation

------------------------------------------------------------

greater-than: INT | FLOAT
less-than: INT | FLOAT
within-range: INT | FLOAT, INT | FLOAT

Pretty self explanatory. With regard to strings however, 
the string length is compared against the params.

------------------------------------------------------------

is-unique: (func) connection(host,user,pass), (func) map(table, field)

Check the value against a field in the database to see if
it's unique.

------------------------------------------------------------

date & time validations

This i'm a bit worried about in terms of terminology. I also
want to include dynamic vars in VRS such as

@now
@today
@thisMonth
@thisYear

------------------------------------------------------------

before: STRING | VAR
after: STRING | VAR

Again, self explanatory. Although I'm unsure what the date/time
format should be. UTC?


------------------------------------------------------------

Elapsed Time:

I'm completely stuck on how to handle conditions like
"years elapsed since date is more than 16"

I don't relish the idea of rules as prolix as

years-elapsed-since-now-are-more-than:18;
years-elapsed-since-now-are-less-than:18;

最后,我在辩论,开发者应该能够在VRS中指定错误/警告,还是应该在处理响应时这样做？

所以,这需要很多东西,我希望它很清楚.我的问题是我的问题

1. 好主意/坏主意？
2. 这是正确的语法吗？
3. 是否有更优雅的方式来命名规则.
4. 少了什么东西.

谢谢

---

更新:有些人说这个提出的系统是一个坏主意.如果您这么认为,请提供一个不起作用的方案.认为这是一个坏主意是一回事,证明这是另一个坏主意,我希望看到证据表明这是一个坏主意,而不是更晚.如果您真的认为表单验证不容易或不那么繁琐,请解释原因.

另外,我知道表单验证不是一个新问题.但是,目前还没有可解决表单验证的可移植,跨平台,跨语言的解决方案,这正是本提案专门针对的问题.

Answer 1

我也喜欢将错误消息放入 VRS 中的想法。但他们应该具体说明失败的规则。

另外，您可能会考虑不开发一种全新的“语言”，而是使用YAML之类的东西，其解析已经存在。

我认为这种语言很有用，因为您可以使用相同的 VRS 进行客户端和服务器端验证。

PS：我认为这应该是社区维基。