spécification des exigences de forme HTML

Question

Je suis en train de construire un framework qui validera les formulaires côté client (javascript) et côté serveur en fonction d'une spécification de spécifications de formulaire écrite en json. Le but est de se débarrasser du code logiquement équivalent sur le serveur et le client pour rendre le code plus facile à maintenir, plus rapide à écrire et moins bogué.

Le format de spécification peut ressembler à:

{ '<field_name>' : ['<validation_function>', 'req', ['<requirement>', <param>], ...], ... } 

(la liste des besoins est ordonnée afin que l'utilisateur peut obtenir la plupart des messages d'erreur de base d'abord, l'exigence de « req » doit venir d'abord si elle existe et des moyens que le champ est obligatoire)

par exemple)

{ 
    'name' : ['string', 'req', ['min',6], ['max',150], ['match', /^[\sa-z0-9ÅÄÖåäö&]$/i], ['not_match', /^tmp_/]], 
    'email' : ['email', 'req'], 
    'email_confirm' : ['same_as', 'email'], 
    'password' : ['string', 'req', ['min', 6], ['max', 64], ['match', /^[a-z0-9\!@#\$%^&*_+.]$/i] ], 
} 

est-ce que quelqu'un sait d'une technologie similaire? Je pense que le cadre de validation de Rails résout le problème au mauvais niveau parce que j'ai constaté que les formulaires fonctionnent souvent sur plus d'un modèle.

Answer 1

Je sais que Django a aussi un framework de validation. Mais cela arrive également dans le back-end. Mais que se passe-t-il si le back-end est le seul endroit qui peut savoir si les données entrées sont valides? Peut-être que l'utilisateur de ce système de validation veut s'assurer que l'adresse e-mail n'est pas déjà utilisée pour un autre compte, par exemple. Alors cette vérification ne peut pas avoir lieu côté client.

Answer 2

Avez-vous envisagé de réutiliser la validation du backend via XMLHttpRequest et de renvoyer tous les détails de l'erreur au format JSON pour faciliter la mise à jour du formulaire afin d'afficher les erreurs? Simon Willison a mis un example of doing so en utilisant l'excellent module django.forms de Django dans sa présentation Advanced Django (à partir de la diapositive 56). Aussi agréable que cela puisse être, je voudrais aussi gratter la même démangeaison, ce qui explique pourquoi j'ai commencé porting django.forms to JavaScript in js-forms, ce qui est assez loin, mais aussi loin d'être prêt pour son usage prévu, qui utilise le même code de base pour exécuter les validations appropriées sur le frontend et le backend en utilisant les mêmes définitions d'objet Form.

Answer 3

Mais mais ... il y a eu des façons de faire des modèles/formes imbriqués dans les rails avant, et dans la version 2.3, il y a eu un bon support, n'est-ce pas?

Voir rails 2.3 releasenotes (#nested object forms))

pas que tout le monde utilise des rails, bien sûr :)