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