RoR and controle de text_field

[khzied]

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 :)
--~--~---------~--~----~------------~-------~--~----~
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@...
Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscribe@...
-~----------~----~----~----~------~----~------~--~---

[cyril mougel]

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 :)

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

--
Cyril Mougel
http://blog.shingara.fr/


--~--~---------~--~----~------------~-------~--~----~
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@...
Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscribe@...
-~----------~----~----~----~------~----~------~--~---

[Michel Belleville]

2009/10/19 Cyril Mougel <cyril.mougel@...>

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 :)

Oui en ajoutant un Michel Belleville 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 Belleville

--~--~---------~--~----~------------~-------~--~----~
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@...
Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscribe@...
-~----------~----~----~----~------~----~------~--~---

[etaque]

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 Belleville <michel.belleville@...>:

> 2009/10/19 Cyril Mougel <cyril.mougel@...>
>>
>> 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 :)
>>
>> Oui en ajoutant un Michel Belleville 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 Belleville
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@...
Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscribe@...
-~----------~----~----~----~------~----~------~--~---

[Michel Belleville]

2009/10/19 Emilien Taque <etaque@...>

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 Belleville

--~--~---------~--~----~------------~-------~--~----~
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@...
Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscribe@...
-~----------~----~----~----~------~----~------~--~---

[etaque]

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 Belleville <michel.belleville@...>:

> 2009/10/19 Emilien Taque <etaque@...>
>>
>> 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 :
>
> 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)
> 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)
> 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)
> 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 Belleville
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@...
Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscribe@...
-~----------~----~----~----~------~----~------~--~---

[Michel Belleville]

2009/10/19 Emilien Taque <etaque@...>

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 Belleville

--~--~---------~--~----~------------~-------~--~----~
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@...
Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscribe@...
-~----------~----~----~----~------~----~------~--~---

[etaque]

Amusant, ça vient de passer sur le blog de Rails :
http://github.com/grimen/validatious-on-rails/

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

2009/10/19 Michel Belleville <michel.belleville@...>:

> 2009/10/19 Emilien Taque <etaque@...>
>>
>> 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 Belleville
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@...
Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscribe@...
-~----------~----~----~----~------~----~------~--~---

[Michel Belleville]

Sounds tasty.

Michel Belleville

2009/10/22 Emilien Taque <etaque@...>

Amusant, ça vient de passer sur le blog de Rails :
http://github.com/grimen/validatious-on-rails/

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

2009/10/19 Michel Belleville <michel.belleville@...>:

> 2009/10/19 Emilien Taque <etaque@...>
>>
>> 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 Belleville
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@...
Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscribe@...
-~----------~----~----~----~------~----~------~--~---