gest_crans_lc

Il s'agit du programme visant à remplacer l'ancien gest_crans en utilisant le nouveau binding ldap.

En tant qu'utilisateur vous pouvez l'utiliser en lançant sur zamok

samir@zamok $ crans_lc

au lien de la commande crans.

Pour info, crans_lc accepte des arguments pour faciliter les tests et le debug :

samir@zamok $ crans_lc -h
[sudo] password for samir on zamok: 
usage: gest_crans_lc.py [-h] [--test] [--debug] [login]

Interface utilisateur du système de gestion des machines et adhérents du
crans

positional arguments:
  login       Se connecter en tant qu'un autre utilisateur

optional arguments:
  -h, --help  show this help message and exit
  --test      Utiliser la base de test
  --debug     Afficher des info de débug comme les tracebacks

Tout le monde peut utiliser la base de test.

Vous êtes sûr de l'utiliser s'il est inscrit en haut du menu principal : Vous êtes connectés en tant que login sur la base de test.

Seule les nounous peuvent utiliser le script en tant qu'un autre utilisateur.

Paradigme de programmation

Pour l'immense majorité du code, gest_crans_lc est écrit Continuation-passing style, c'est-à-dire qu'au lieu de retourner une valeur, on passe à chaque fonction un (ou plusieurs) callback qu'elle doit appeler à la fin de son exécution.

Cela est implémenté ici grâce à deux classes :

• TailCall qui représente un callback : une fonction et ses arguments. Les arguments peuvent être modifiés après l'initialisation en appelant un TailCall comme une fonction.

• Continue qui représente une exception. En levant un Continue avec comme argument un TailCall, la fonction du TailCall est ensuite exécutée sur les arguments contenus dans le TailCall

Une fonction affichant un menu dialog

Une fonction utilisant dialogue se compose en général de deux sous fonctions :

• une fonction gérant l'affichage du menu dialog, généralement appelé box

• une fonction gérant les valeurs retournées par dialog, généralement appelée todo

Ça nous donne :

    def ma_fonction(self, …, cont, …):
        def box(box_arg1, …):
            …
            return self.dialog.WIDGET(args1, …)

        def todo(todo_arg1, …, cont):
            …
            raise Continue(cont(cont_argn=togo_argk))

        retry_cont = TailCall(self.ma_fonction, …, cont=cont, …)
        (code, output) = self.handle_dialog(cont, box, box_arg1, …)

        return self.handle_dialog_result(
            code=code,
            output=output,
            cancel_cont=cont,
            error_cont=retry_cont,
            codes_todo=[
              ([self.dialog.DIALOG_OK], todo, [todo_arg1, …, cont]),
            ]
        )

Les fonctions handle_dialog et handle_dialog_result permettent de gérer sans peine les rattrapages d'exception, ctrl-C ou ESC.

Généralement, les codes de retour de dialog sont binaire (ok ou annuler), s'il y en a d'autre, les ajouter à la liste codes_todo avec une autre fonction todo pour les prendre en charge.

Dans l'exemple ici en cas d'annulation, on exécute le TailCall cont (sans doute retourner au menu parent), en cas d'erreur, elle est affichée par handle_dialog_result puis retry_cont est appelé : la fonction est réexécutée et l'utilisateur peut corriger les informations à l'origine de l'exception.

Si todo est exécuté, on retourne en exécutant le TailCall cont en y mettant certains paramètres à jour (par exemple l'objet que l'on vient de modifier).

Comme vous avez pu le remarquer, on ne se préoccupe absolument pas de savoir d'où vient la fonction et où elle va. On appel juste la continuation lorsqu'on a fini ce qu'on avait à faire et tout se passe bien. Cela permet d'utiliser plus facilement la même fonction à plusieurs endroit du code et de construire naturellement des chaînes d'annulation (tu annules, j'exécute cont, qui fera de même si tu annules encore).

CatégoriePagePublique