RoR and controle de text_field

Community FR
1

Salut tout le monde,

J’ai un pb au niveau des “form_tag”. Je veux controler les données
saisies dans le champ text_field… Comme par exemple, dans le cas où
j’accepte pas qu’à l’envoie des informations, un champ soit vide… Ces
controles se font au niveau de la vue…

Merci :slight_smile:

2

Zied a écrit :

Salut tout le monde,

J’ai un pb au niveau des “form_tag”. Je veux controler les données
saisies dans le champ text_field… Comme par exemple, dans le cas où
j’accepte pas qu’à l’envoie des informations, un champ soit vide… Ces
controles se font au niveau de la vue…

Merci :slight_smile:

Oui en ajoutant un Michel B. dedans (comprendre JQuery non
obstrusive)

–
Cyril M.

3

2009/10/19 Cyril M. [email protected]

Oui en ajoutant un Michel B. dedans (comprendre JQuery non
obstrusive)

(Je devrais peut-être penser à faire du merchandising, genre une ligne
de
tee-shirts ou des casquettes…)

Admettons que tu le fasse, comme suggère notre ami Cyril, avec jQuery ça
donnerait ça :

$(‘#id_de_ton_form’).submit(function(event) {
var errors = false;
$(this).find(‘textarea’).each(function() {
if ($(this).value().match(/^\s*$/)) {
errors = true;
$(this).class(‘error’); // adapter à ce que tu veux obtenir
}
});
if (errors) {
event.preventDefault();
alert(“t’as laissé plein de champs vides gros ballot”); // adapter si tu
veux éviter que tes utilisateurs se sentent insultés
}
});

Par exemple.

Michel B.

4

Ca doit se faire de brancher un validateur JS basé sur les validates_
des modèles avec un peu d’introspection, quelqu’un a déjà fait ça ?

(un peu HS car Zied parle de form_tag…)

2009/10/19 Michel B. [email protected]:

5

2009/10/19 Emilien T. [email protected]

Ca doit se faire de brancher un validateur JS basé sur les validates_
des modèles avec un peu d’introspection, quelqu’un a déjà fait ça ?

J’ai pas arrêté de faire des trucs comme ça avant de connaître Rails, en
général c’est assez chiant à bien faire parce qu’il vaut mieux éviter de
trop charger la mule question requêtes AJAX dans le vent et que ça
oblige de
faire dans les contrôleurs une méthode de sauvegarde à blanc juste pour
tester si les champs sont corrects (qui peut être simplement un
paramètre de
plus que va attraper la méthode create / update), des calls AJAX
déclenchés
à chaque modification d’un champ du formulaire qui reçoivent la réponse,
listent les champs erronés dans la réponse et agissent en conséquence
dans
la page. C’est pas infaisable si tu organise bien tes formulaires et si
tu
fais bien tes validations dans tes modèles, mais dans la plupart des cas
c’est pas forcément beaucoup plus ergonomiques que de vérifier les
grosses
erreurs évidentes sans AJAX (champs vides, champs numériques avec des
lettres, etc.), d’envoyer le formulaire en AJAX pendant la soumission et
afficher le résultat de la validation quand elle est négative si ça
passe
pas.

Ceci dit si c’est une demande ferme de tes utilisateurs ça peut être
intéressant de faire quelque chose de composite, du genre :

  1. ne surveiller que les champs “Ã risque” (par exemple en leur
    mettant
    une classe “validated” ; pour éviter de trop se répéter, tu peux
    ouvrir les
    helpers de formulaire de Rails, leur filer un peu d’introspection
    pour
    savoir s’il y a des validate sur ce champs dans le model et leur
    faire avoir
    la classe validated quand c’est le cas)
  2. quand un champs surveillé est modifié, call AJAX sur la cible du
    formulaire en ajoutant un paramètre “validation” pour dire que c’est
    Ã blanc
    (en mettant toujours le même paramètre “validation”, tu peux ne faire
    qu’un
    seul callback sur tous les champs qui ont “validated”, chopper l’url
    sur
    laquelle pointe ton form, sérialiser le contenu du form pour faire ta
    requête et ajouter le paramètre “validation” dans la foulée pour
    faire ton
    call AJAX)
  3. le contrôleur reçoit “validation”, il lance un create / update
    dans
    une transaction (et si ça passe il rollback ; toujours pour ne pas te
    répéter, tu peux donner faire des méthodes blank_create et
    blank_update Ã
    ActiveRecord::Base qui vont faire un create / update dans une
    transaction et
    toujours faire rollback derrière en renvoyant l’objet avec ses
    erreurs de
    validation) ; il renvoie un statut 200 si tout va bien, sinon il
    renvoie un
    statut 4xx pour dire qu’il y a une erreur dans les paramètres
    accompagné
    d’une liste json des erreurs de validation (mappé nom_du_champs:
    “texte
    d’erreur” par exemple)
  4. un callback sur la méthode AJAX choppe les erreurs de validation
    dans
    le json, lit le nom des champs, trouve les champs dans le formulaire,
    les
    encadre en rouge (etc.) et ajoute le texte d’erreur dans un span avec
    une
    class qui dit “error” (de nouveau si tu t’es bien débrouillé pour
    faire une
    mécanique standard la méthode JavaScript qui fait ça devrait être
    assez
    facile)

Au final ça peut sembler gros et complexe mais ça ne l’est pas tant que
ça
si tu pense bien réutilisable dès le début. Par contre si tu commence
une
méthode comme ça en artisanal sur juste un modèle en faisant pas propre
dès
le début, il faut t’attendre à ce qu’on te demande de généraliser, et
dans
ce cas tu t’en mordras très probablement les doigts de ne pas avoir fait
réutilisable dès le début…

Dans tous les cas, ça ne doit en aucun cas remplacer un traitement
harmonieux et strict des validations “à la papa” (c’est à dire lors de
la
“vrai” requête de sauvegarde).

Michel B.

6

J’imaginais plutôt des classes spécifiques sur les champs, générées
via introspection par exemple avec l’aide de formtastic, qui
permettent de déclencher des validateurs JS locaux, typiquement un
class=“required” et un jquery-validator qui fait le boulot.
Moins coûteux que de l’appel ajax ?

2009/10/19 Michel B. [email protected]:

7

Amusant, ça vient de passer sur le blog de Rails :

Validation javascript unobtrusive générée par introspection. A tester !

2009/10/19 Michel B. [email protected]:

8

Sounds tasty.

Michel B.

2009/10/22 Emilien T. [email protected]

9

2009/10/19 Emilien T. [email protected]

J’imaginais plutôt des classes spécifiques sur les champs, générées
via introspection par exemple avec l’aide de formtastic, qui
permettent de déclencher des validateurs JS locaux, typiquement un
class=“required” et un jquery-validator qui fait le boulot.
Moins coûteux que de l’appel ajax ?

Oui, on peut même tout à fait combiner ces deux approches (l’une des
demandes récurrentes pour ce genre de méthodes c’est de prévalider les
données pour éviter de retourner après-coup les erreurs vérifiables que
sur
le serveur comme les doublons de nom, les dépendances, etc. qui ont
besoin
d’un call ajax) et effectivement l’approche côté client est “sans coût”
puisqu’elle ne chatouille pas le serveur.

Michel B.