Ce blog a déménagé et parle maintenant uniquement anglais.

This blog has moved and now only speaks English.

blog.floriancargoet.com

See you there!

/home/florian

le blog de florian cargoet : du linux, du web et du logiciel libre



ExtJS EditorGridPanel, validation et accès au record dans le validator

14 March, 2010 (20:57) | Ext JS, Webdev | Florian Cargoet

Catégorie Webdev : A propos du web, de son contenu, de ses outils...

Si vous n’avez jamais utilisé l’EditorGridPanel d’ExtJS, le titre peut paraitre un peu obscur donc je vais commencer par rappeler ce qu’est l’EditorGridPanel ainsi que les possibilités de validation offertes par ExtJS. Enfin, l’objet principal de cet article, nous verrons comment pousser un peu plus loin les possibilités du validator en lui donnant accès aux autres colonnes de l’EditorGridPanel.

Cet article mélange donc une introduction à l’EditorGridPanel, une présentation de quelques techniques de validation et une technique avancée pour aller plus loin. Il y en a donc pour tous les niveaux, faites le tri.

Un GridPanel éditable

Si vous ne connaissez pas le GridPanel, cet article ne vous sera que de peu d’intérêt (je vous invite à jeter un oeil sur les exemples d’ExtJS) donc je passe directement à l’EditorGridPanel.

Le principe est très simple : vous avez un tableau présentant des données dans votre application et vous voulez pouvoir les modifier directement depuis le tableau. La mise en œuvre est tout aussi simple : remplacer votre GridPanel par un EditorGridPanel et spécifier un Editor pour chaque colonne éditable. ExtJS se chargera d’afficher l’éditeur (en général un champ de saisie de texte, mais cela peut être le widget de sélection de date par exemple), de contrôler que les données saisies sont valides et de mettre à jour le Store sous-jacent. Bien évidemment, le type de l’éditeur et les conditions de validation sont paramétrables.

Tous les exemples présentés dans cet article sont rassemblés dans une démo que vous pouvez regarder avant de plonger dans les explications. Pour tous les exemples présentés, les données utilisés sont les suivantes :

Pour commencer, essayons de mettre en place un petit exemple d’EditorGridPanel avant de nous pencher sur la validation.

Validation des valeurs saisies

Maintenant que l’on sait éditer les données d’un EditorGridPanel, occupons nous d’empêcher l’utilisateur de saisir des valeurs erronées.

Note : la validation des données coté client n’est pas suffisante car on peut toujours soumettre des données à votre serveur sans passer par votre application et y injecter des valeurs erronées voire des valeurs dangereuses (injections SQL, XSS…). Bref, faites de la validation coté serveur, la validation coté client est là pour le confort de l’utilisateur.

Il existe plusieurs mécanismes dans ExtJS pour valider les valeurs saisies :

  • le contrôle a priori, en empêchant la saisie de certains caractères. Par exemple, pour un champ numérique, vous pouvez n’autoriser que la saisie des nombres, du séparateur décimal et éventuellement les signes + et -.
  • le contrôle en continu (à chaque touche), qui indique que la donnée n’est pas valide et affiche un message d’erreur permettant de le corriger. Par exemple, pour la saisie d’une adresse email, vous pouvez afficher un message d’erreur tant que le champ n’est pas au format login@serveur.tld.
  • le contrôle a posteriori qui invalide la saisie et réinitialise la cellule.

Pour le contrôle a priori, vous pouvez utiliser l’option maskRe sur un éditeur TextField ou vtype (les vtypes sont des types fournis par ExtJS qui font aussi de la validation en continu comme nous le verrons plus loin) :

Pour le contrôle continu vous pouvez utiliser maxLength, minLength pour limiter la taille, regex pour contrôler la correspondance avec une expression régulière, validator pour spécifier une fonction qui se charge de la validation ou encore vtype pour valider certains formats courants et déjà implémentés dans ExtJS (alpha, alphanum, email, url). Les vtypes permettent également de faire du filtrage sur les caractères saisis (comme maskRe). Un exemple utilisant tout ça :

Pour le contrôle a posteriori, vous pouvez exploiter les évènements beforecomplete (lancé par l’Editor) ou validateedit (lancé par l’EditorGridPanel) :

Valider les valeurs en fonction des autres colonnes

Nous savons maintenant éditer des cellules et contrôler les valeurs saisies par l’utilisateur. Tentons maintenant d’effectuer la validation d’une valeur en fonction de la valeur des autres colonnes. Un éditeur étant attaché à une seule cellule, il n’a pas accès aux autres colonnes. Nous allons donc ruser et lui donner accès au Record dont provient le champ en cours d’édition (c’est-à-dire lui donner accès aux données des autres colonnes sur la même ligne) ! Pour parvenir à cela, nous allons combiner l’utilisation de la fonction validator et de l’évènement beforeedit (lancé par l’EditorGridPanel). La fonction validator a accès à la valeur à valider (passée en paramètre) mais a aussi accès à l’instance de Field qui sert d’éditeur via le mot-clé this. Nous allons donc nous débrouiller pour passer au Field le Record en cours d’édition. Le validator y aura ainsi accès et pourra faire un traitement de la valeur en fonction de toutes les valeurs contenues dans le Record. Pour passer ce Record au Field, nous allons profiter de l’évènement beforeedit pour insérer une propriété currentRecord dans le Field qui sert d’éditeur. Je récapitule :

  1. On capture l’évènement beforeedit
  2. On place une référence vers le Record en cours d’édition dans le Field qui sert d’éditeur
  3. Le validator y accède via this.currentRecord

En pratique, ça donne :

Conclusion

J’espère que tout est clair, si ce n’est pas le cas, n’hésitez pas à demander des éclaircissements dans les commentaires. Sachez que tout ce qui concerne la validation des données est valables également pour les formulaires puisque les mécanismes de validation sont implémentés dans les Fields qui sont également utilisés par les formulaires. Enfin, tout le code est récupérable sur GitHub.

Article suivant :
»

Commentaires

Commentaire de Jérôme
le 7 April 2010, 16:07

Salut, t’aurai pas une technique pour valider côté serveur et afficher les cellules qui sont en erreur? que ce soit en mode batch ou autosave… J’ai beau me casser la tête à chercher un moyen je ne trouve rien de probant.

Commentaire de Florian Cargoet
le 7 April 2010, 19:47

Le coté asynchrone de la chose me fait penser que tu veux afficher les éventuelles erreurs après qu’une (ou plusieurs) cellule ait été modifiée et non pas du contrôle avant d’accepter la modification coté client.
J’ai rien de tout fait sous la main mais quelque chose dans ce genre me semble ressembler à ce que tu cherches (édite une ligne de numéro impair, le serveur renverra une erreur). Si tu écoutes l’évènement exception pour capter les erreurs renvoyées par le serveur, tu peux appliquer une classe css sur la cellule (quitte à écraser la background-image de .x-grid3-dirty-cell).

Commentaire de jluc
le 31 July 2010, 16:53

Joli article sur l’EditorGridPanel et la validation. vraiment cool! Merci