СУХАЯ валидация пользовательского ввода (на стороне клиента, на стороне сервера) с использованием JSON-схемы

Question

В рамках обширного тестового примера я создаю CMS-подобное приложение на основе ajax, которое обеспечивает CRUD-функциональность для различных типов документов, например статей, тегов и т. Д.

на сервереи на стороне клиента я рассматриваю возможность использования JSON-схемы (http://json -schema.org / ) в качестве способа выполнения проверки ввода пользователя в режиме СУХОЙ (то есть: 1 схема проверки, чтобыиспользоваться как на сервере, так и на стороне клиента, без дубликата кода и все такое).Это выглядит замечательно, потому что:

• JSON-схема реализована в JS и Java, поэтому теоретически одна схема может обрабатывать проверку на стороне клиента и на стороне сервера

• все запросы и ответы CUD-операций выполняются в формате JSON (через ajax)

Однако помимо обычных проверок пользовательского ввода я хотел бы провести некоторые дополнительные проверкисервер (например: например, проверка, если имя тега, который пользователь хочет создать, уже существует)

В идеале, я хочу, чтобы эти типы проверок были включены в мой общий код проверки на стороне сервера (который, как сказано, будетосновываться на JSON-схеме).Однако я не совсем уверен, что это правильный подход, потому что эти дополнительные проверки не основаны только на предоставленных JSON-данных, но требуют дополнительных данных для проверки (например, имена существующих тегов в системе, чтобы проверить,имя тега уже существует).

Итак, будет ли хорошей идеей (с точки зрения дизайна / архитектуры) включить дополнительные проверки, подобные описанным выше, в основанную на json-схеме схему проверки на стороне сервера?Будет ли это элегантным решением?Или вы бы держали их отдельно?Если нет, то почему и какой другой альтернативе вы бы предложили остаться СУХОЙ в отношении проверки на стороне клиента и на сервере?

Как вы думаете?

Некоторые дополнительные контексты / цели приведенного ниже текстового случая для некоторой справочной информации.

Спасибо, Geert-Jan

---

Некоторые контексты / цели:

• CMS на основе ajax с использованием подхода REST

• CUD-запросы выполняются через ajax с использованием подхода rest (т. Е. Отображение на POST, PUT, DELETE соответственно).Все запросы и ответы выполняются через JSON.

• CMS без форм.Вместо этого используйте редактирование на месте (например, используя Aloha-редактор: http://www.aloha -editor.org /

• , оставаясь сухим.

  1. Шаблонирование: сделано с помощью шаблонов усов на стороне клиента и сервера. Первоначальный рендеринг и инкрементальный рендеринг через ajax выполняются на основе одного и того же шаблона. Я хотел пойти на что-то другое, чем усы (из-за отсутствиявыразительная сила), но он работает как минимум для этого прототипа (см. предыдущий вопрос об альтернативах, на который я все еще ищу ответ: Клиентский язык шаблонов также с компилятором java (DRY-шаблоны) )

  2. СУХАЯ проверка входа: как описано выше

---

Поток проверки (в случае сбоя):

1. пользователь создает / обновляет / удаляет элемент.

2. ошибка проверки на клиенте мгновенно дает пользователю обратную связь, как чтовосстановить. (Javascript JSON-схема-валидатор would в идеале вернуть JSON, который отформатирован для пользователя)

3. , когда проверка на стороне клиента завершается успешно, операция CUD выполняется с использованием ajax.

4. в случае сбоя проверки на стороне сервера возвращается код состояния 400 (неверный запрос) с Json-объектом, содержащим сбой (ы) валидации, которые подхватываются jqueryerror-callback

   $.ajax({
       ....
       error: function(xhr, status, error) {
           var validationJSON = JSON.parse(xhr.responseText);
           //handle server-side validation failure 
       },
       ....
   });
   

5. JSON-объект, содержащий ошибки проверки на стороне сервера, предоставляется пользователю (аналогично стороне клиента)

Answer 1

Очень возможно и очень приятно иметь одно определение проверок в одном месте (для каждой модели) на сервере, которое затем может генерировать соответствующий JS для проверок на стороне клиента и на основе AJAX.

Фреймворк Yii для PHP имеет фантастическую архитектуру для элегантного выполнения этого, в которой все правила валидации хранятся вместе в модели (разделенной на соответствующие «сценарии» по мере необходимости). Оттуда нужно щелкнуть несколько переключателей, чтобы сделать конкретную форму клиентской или AJAX-проверяемой. Я полагаю, что интерфейсы Yii для этого были основаны на Rails.

В любом случае, я очень рекомендую проверить следующие ключевые моменты в дизайне Yii; даже если вы не знаете PHP, вы можете использовать его для вдохновения:

• CModel::rules() => СУХОЙ источник правил проверки моделей
• CActiveForm => Используется для создания элементов формы на основе атрибутов модели
  • См., Например, CActiveForm::textField()
• CValidator => Базовый класс для валидаторов, который обеспечивает возможность подтверждения клиентом

Я думаю, что стоит придерживаться декларации правила проверки DRY, и, по моему опыту, совсем нереально добиться этого 100% и при этом иметь богатые формы и богатые правила проверки. (И мальчик, ты будешь любить жизнь, когда тебе не придется управлять всей этой проверяющей клиента JS ...)

Надеюсь, это поможет.