ОБНОВЛЕНИЕ: В комментариях было предложено создать для этого вики. Я сделал, вы можете найти его здесь (если вы хотите следить за этим и / или внести свой вклад).
http://vrs.tomelders.com
Я никогда раньше не работал над чем-то подобным, поэтому я полностью облажался.
Я никогда не работал над чем-то подобным, поэтому, пожалуйста,
Я хочу работать над открытым "стандартом" или "языком", или ... ну, я не знаю, как это назвать .... чтобы упростить проверку формы. Я называю это VRS (листы правил валидации), но на данном этапе все является предметом переговоров.
Идея состоит в том, чтобы создать лист правил, похожий на CSS, который определяет, как формы должны проверяться. Это потребует
- Синтаксис / Спецификация
- Парсер VRS для преобразования VRS во что-то полезное
- Процессор VRS для сравнения данных формы с правилами и возврата ответа.
- Формат ответа.
Преимущества такой системы будут
- Платформенный / языковой независимый способ определения валидации форм.
- Кроссплатформенный, очень переносимый способ определения форм валидации.
- Легко читается, легко настраивается, легко модифицируется.
- Клиентская и внутренняя интеграция.
Хотя обо всем по порядку. Как должен выглядеть синтаксис / спецификация.
Я вижу эту работу в Интернете так, что файл VRS может быть указан как скрытое поле, и приложение направляет предоставленные данные формы через процессор VRS перед обработкой.
В качестве примера, вы можете проверить, что тип содержимого поля «name» будет выглядеть так:
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, или они должны делать это при обработке ответа?
Итак, это много, и я надеюсь, что это понятно. Мои вопросы, я думаю,
- Хорошая идея / плохая идея?
- Это правильный вид синтаксиса?
- Существуют ли более элегантные способы именования правил.
- Чего не хватает.
спасибо
ОБНОВЛЕНИЕ: Несколько человек заявили, что эта предложенная система - плохая идея. Если вы так думаете, приведите сценарий, в котором он не будет работать. Думать, что это плохая идея, это одно, доказывать, что это плохая идея, это другое, и я хотел бы увидеть доказательство того, что это плохая идея раньше, чем позже. Если вы действительно думаете, что проверка формы не может быть проще или менее утомительной, объясните, почему.
Кроме того, я знаю, что проверка формы не является новой проблемой. Однако в настоящее время не существует портативного, кросс-платформенного, кросс-языкового решения для проверки правильности формы, к чему конкретно относится это предложение.