DRY validación de entrada de usuario (cliente, servidor) usando el esquema JSON

Question

Como parte de un extenso caso de prueba, estoy construyendo una aplicación similar a CMS basada en ajax que proporciona funcionalidad CRUD en varios tipos de documentos, por ejemplo: artículos , etiquetas, etc.

en el servidor y el cliente Estoy considerando utilizar el esquema JSON (http://json-schema.org/) como una forma de hacer la validación de entrada de usuario de forma SECA (es decir: 1 esquema de validación, para ser usado tanto en el servidor como en el lado del cliente, sin código duplicado y todo eso). Esto parece muy bien, porque:

• JSON-esquema es a la vez implementado en JS y Java, por lo que un esquema pude en la validación del lado del cliente mango teoría y del lado del servidor

• todas las solicitudes CUD-operaciones y las respuestas son JSON (a través de Ajax)

Sin embargo, además de las validaciones habituales en la facilidad de entrada me gustaría tener algunos controles adicionales en el servidor (por ejemplo: como la comprobación de si el nombre de una etiqueta de un usuario desea crear ya existe)

Lo ideal es que este tipo de comprobaciones se incluyan en mi código general de validación del lado del servidor (que, como se dijo, se basaría en el esquema JSON). Sin embargo, no estoy del todo convencido de que este sea el enfoque correcto, porque estas comprobaciones adicionales no se basan solo en los datos JSON proporcionados, sino que necesitan datos adicionales para validar (por ejemplo, los nombres de las etiquetas existentes en el sistema para verificar si un nombre de etiqueta ya existe).

Entonces, ¿sería una buena idea (de diseño/arquitectónico) incorporar verificaciones adicionales como la descrita anteriormente en el marco de validación basado en el esquema json en el lado del servidor? ¿Esta sería una solución elegante? ¿O los mantendría separados por completo? De no ser así, ¿por qué no y qué otra alternativa se planteó sugeriría que se mantenga DRY con respecto a la validación del lado del cliente y del servidor?

¿Qué opinas?

Algunos contextos/objetivos adicionales de la siguiente caja de texto para obtener información general.

Gracias, Geert-Jan

---

un poco de contexto/objetivos:

• CMS utilizando el enfoque REST

• CUD-solicitudes se realizan a través de ajax usando un basadas en Ajax enfoque de reposo (es decir: mapeo en POST, PUT, DELETE, respectivamente). Las solicitudes y las respuestas se realizan a través de JSON.

• CMS sin formularios. En lugar de utilizar la edición in situ (por ejemplo, utilizando Aloha-editor: http://www.aloha-editor.org/

• permanecer seco

  1. de plantillas:.. hecho a través de plantillas bigote en el cliente y en el servidor de representación Intial y la representación incremental a través de ajax son hecho en base a 1 y la misma plantilla. Quería ir por algo diferente a Moustache (debido a su falta de poder expresivo), pero al menos funciona para este prototipo.(Véase la pregunta anterior de alternativas, en el que todavía estoy buscando una respuesta: Client-side templating language with java compiler as well (DRY templating))

  2. SECO entrada de validación: como se describió anteriormente

---

flujo de validación (en caso de fallo):

1. usuario crea/actualiza/borra elemento.

2. una falla de validación en el cliente daría instantáneamente comentarios al usuario sobre qué reparar. (El Javascript JSON-schema-validator idealmente devolvería JSON, que está formateado para el usuario)

3. cuando la validación del lado del cliente se realiza correctamente, la operación CUD se realiza con ajax.

4. si la validación del lado del servidor falla, un estado de código 400 (solicitud incorrecta) se devuelve, con un JSON-objeto que contiene la validación de fallo (s) que se recogió por error-devolución de llamada de jquery

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

5. JSON a objetos que contienen errores de validación del lado del servidor se presenta al usuario (de forma análoga a la del lado del cliente)

Answer 1

es muy posible y una de las cosas más gratificantes para tener una sola definición de validaciones en un lugar (por modelo) en el servidor que luego puede generar JS apropiado para validaciones basadas en el lado del cliente y basadas en AJAX.

Yii framework para PHP tiene una arquitectura fantástica para lograr esto de una manera elegante que almacena todas las reglas de validación juntas en el modelo (dividido en "escenarios" apropiados según sea necesario). A partir de ahí, se trata de activar algunos modificadores para hacer una forma particular del lado del cliente o AJAX-validable. Creo que las interfaces de Yii para esto se basaron en Rails.

De todos modos, recomendaría revisar los siguientes puntos clave del diseño de Yii; incluso si usted no sabe PHP, puede utilizar esto para la inspiración:

• CModel::rules() => La fuente DRY para las reglas de validación de modelos
• CActiveForm => Se utiliza para generar elementos de formulario basado en el modelo atributos
  • Véase, por ejemplo CActiveForm::textField()
• CValidator => clase base para validadores qué disposiciones para the ability to client-validate

Creo que es sensato seguir con la declaración de reglas de validación DRY y en mi experiencia no es del todo realista lograr ese 100% y aún así tener formas ricas y ricas reglas de validación. (Y chico te encantará la vida cuando no tienes que administrar todo ese cliente-validar JS ...)

Espero que esto ayude.