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

Question

更新：评论中建议我为此创建一个维基。我已经完成了，您可以在这里找到它（如果您希望密切关注和/或贡献）。

http://vrs.tomelders.com

我以前从未从事过这样的事情，所以我完全即兴发挥。

---

我以前从来没有从事过这样的事情，所以

我想研究一种开放的“标准”或“语言”，或者......好吧，我真的不知道该怎么称呼它......使表单验证更容易。我称之为 VRS（验证规则表），但在这个阶段，一切都是可以协商的。

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

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

像这样的系统的好处是可以采用

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

首先，首先要做的事情。语法/规范应该是什么样的。

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

举例来说，您可以验证“名称”字段的内容类型，该

name {
    content-type: alpha;
}

内容类型可能是三个值之一：字母、数字或字母数字。

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

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

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：我认为这应该是社区维基。

Answer 2

1. 我认为这是一个好主意，如果您可以自己维护它。

2. 记住，语法是你自己制定的。这取决于你（只要它看起来不错）。

3. 不，不是真的。只要名称很明显（看起来像它们本来的样子），并且不太长或令人困惑，那就可以了。

4. 也许您应该在未指定规则时记下规则的默认值。

Answer 3

1. 好主意/坏主意？

   一般来说，这种事情是一个坏主意。这就是 PHP 的用途。

   http://www.phpformclass.com/ 有什么问题
   http://www.x-code.com/vdaemon_web_form_validation.php
   或其他 PHP 表单管理工具？

2. 这是正确的语法吗？

   没有。 PHP 出了什么问题？对于这种事情，它有很好的语法。

3. 有没有更优雅的方式来命名规则。

   是的。 PHP 对象类。许多其他项目。您不是第一个验证表单输入的人。

4. 缺少什么。

   回答基本问题：PHP 出了什么问题？

   已经执行此操作的相关项目列表以及您的项目优于所有其他现有项目的具体原因。