% svn diff | grep toto
zsh: command not found:  grep

WTF ? Il ne trouve pas grep ?

En fait, c’est très bête comme problème : sur un clavier français, on fait Alt.Gr.+6 pour obtenir le pipe, et si on tape un peu vite, il arrive qu’on tape l’espace qui suit avant d’avoir relâché la touche Alt.Gr. ce qui donne une espace insécable au lieu d’une espace normale (apparemment, c’est le cas pour le layout fr-latin9).

Or, par défaut, le séparateur de mots est l’espace normale donc le shell ne voit pas “grep” mais ” grep” avec une espace insécable. D’où le “command not found”…

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.

Voyez vous même la différence :

Le code

Comme d’habitude, sur GitHub ou directement ici vu que c’est plutôt léger :

<?php
/*
Plugin Name: Categories as Widgets
Plugin URI: http://fcargoet.evolix.net/
Description: Display each top-level category as a widget with its sub categories
Author: Florian Cargoët
Version: 0.1
Author URI: http://fcargoet.evolix.net/
*/
 
function cat_as_widget($args){
    extract($args);
 
    echo $before_widget;
    echo $before_title . $category->name . $after_title;
 
    $cat_args = array('child_of'=>$category->cat_ID,'hierarchical' => false,'title_li'=>'');
 
    echo '<ul>';
    wp_list_categories(apply_filters('widget_categories_args', $cat_args));
    echo '</ul>';
 
    echo $after_widget;
}
 
 
 
function widget_CategoriesAsWidgets($args) {
 
    $categories = get_categories();
 
    foreach($categories as $category){
        if($category->parent==0){ //only toplevel cats
            $args['category']=$category;
            cat_as_widget($args);
        }
    }
}
 
function categoriesAsWidgets_init()
{
    register_sidebar_widget(__('Categories As Widgets'), 'widget_CategoriesAsWidgets');
}
 
add_action("plugins_loaded", "categoriesAsWidgets_init");
?>

Pour visualiser un peu le problème, vous pouvez jeter un oeil à la démo du layout sur le site d’ExtJS et cliquer sur le bouton permettant de réduire la zone “South”.  Une fois réduit, le rectangle qui représente le panel réduit n’apporte pas beaucoup d’informations…

Pour accéder à ce rectangle et y insérer ce que vous voulez :

var component = Ext.getCmp(15);
var el = component.layout.south.collapsedEl;
el.insertHtml('afterBegin','<span style="position: relative; top: 4px; left: 5px; color: #15428b; font-family: tahoma,arial,verdana,sans-serif; font-size: 11px; font-weight: bold;">Et voilà un titre</span>');

Attention : l’élément collapsedEl n’existe qu’après la première réduction du panel donc il faut jouer avec l’évènement collapse.

ssh-keygen -R hostname

Alternativement mais moins sympa, ssh donne la ligne de la clé erronée dans son avertissement ce qui permet de savoir laquelle supprimer.

Avant de faire aveuglément confiance à ce serveur, vous pouvez vérifier l’empreinte de sa clé publique si vous l’avez :

ssh-keygen -l -f ssh_host_dsa_key.pub

Ce fichier se trouve dans /etc/ssh sur le serveur.

UPDATE tablename SET column_name = REPLACE (
    `column_name`,
    `search`,
    `replace`
);

Quelqu’un sait si on peut utiliser des expressions régulières ?

fdisk -l

ou plus précis :

fdisk -l /dev/disque

dpkg-query -W --showformat='${Installed-Size} ${Package}\n'| sort -rn | less

L’intérêt ? Faire un peu de nettoyage quand on manque de place…

Pour changer cela, changer la clé keyword.URL dans l’about:config et c’est gagné !

Voir l’article sur escaline.org pour un cas concret d’utilisation.