syntax - 需要有关创建新 "standard"的建议/"language"

Question

更新:在评论中建议我为此创建一个Wiki。我已经做完了，您可以在这里找到它(您希望保持关注和/或贡献)。

http://vrs.tomelders.com

我以前从来没有做过这样的事情，所以我全力以赴。

我以前从没做过这样的事情，所以请

我想处理一个开放的“标准”或“语言”，或者……好吧，我真的不知道该怎么称呼……以简化表单验证。我称它为VRS(验证规则表)，但在此阶段，一切都是可以协商的。

想法是创建类似于CSS的规则表，以定义应如何验证表单。这将需要

语法/规范

一个VRS解析器，用于将VRS转换为可用的

一个VRS处理器，用于将表单数据与规则进行比较并返回响应。

响应格式。

这样的系统的好处是

定义表单验证的平台/语言不可知方式。

跨平台，高度可移植的定义表单验证的方式。

易于阅读，易于设置，易于修改。

客户端和后端集成。

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

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

通过示例，您可以验证“名称”字段的内容类型如下所示

name {
    content-type: alpha;
}

content-type可以是三个值之一:字母，数字或字母数字。

希望这是有道理的。我以前从未做过这样的事情，所以我很想征询其他人的意见。这是我所得到的

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

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中指定错误/警告，或者他们在处理响应时应该这样做？

因此，需要接受很多工作，我希望这很清楚。我想是

好主意/坏主意？

这是正确的语法吗？

是否有更优雅的规则命名方式。

缺少什么。

谢谢

更新:一些人说这个提议的系统是个坏主意。如果您这样认为，请提供一个无法解决的方案。认为这是一个坏主意是一回事，证明它是一个坏主意又是另一回事，我希望能看到证明它早晚不是坏主意的证据。如果您确实认为无法简化表单验证或使其变得乏味，请解释原因。

另外，我知道表单验证不是一个新问题。但是，目前尚无可移植的，跨平台，跨语言的解决方案来解决表单验证问题，这是该提案专门解决的问题。

Answer 1

我也喜欢将错误消息放入VRS中的想法。但是它们应该特定于失败的规则。

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

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

PS:这应该是社区Wiki方法。