",
la notion de déclencheur est accessible à toutes les extensions, cela
au travers du "descripteur" de leur connexion à l'annuaire LDAP.
-
void connectWindow::resetTriggers ( void ) :
permet de réinitialiser tous les contextes - déjà ouverts - de définitions des
déclencheurs, notamment pour que les prochains appels
de contextes (
cf.: setTriggers() ci-dessous) provoquent une relecture effective des définitions au sein de la base de données LDAP où elles sont stockées.
-
bool connectWindow::setTriggers ( const char* contextName, const char* description ) : permet d'initialiser un nouveau contexte ou de basculer vers un
contexte de définitions de déclencheurs déjà ouvert. Retourne "
true" si des définitions existent, "
false" sinon. Exemples : "
setTriggers ( "
triggerOnEdit", "
triggers on fields edition" ),
setTriggers ( "
triggerOnBackup", "
triggers on fields backup" ),
setTriggers ( "
triggerOnDelete", "
triggers on fields delete" ),
setTriggers ( "
triggerOnDisplay", "
triggers on fields displaying ), etc.
-
bool connectWindow::hasTrigger ( const char* fieldName ) : permet de savoir si un déclencheur est défini pour le champ (attribut) de nom "
fieldName".
-
void connectWindow::insertTriggeredField ( const char* fieldName ) :
permet d'ajouter au context courant un nom de champ auquel pourra
ensuite être éventuellement associée une définition de déclencheur (lors
de l'appel à
openTriggersForm(), décrite ci-dessous).
-
void connectWindow::openTriggersForm ( bool writable ) : permet d'ouvrir la fenêtre d'édition (ou d'affichage si "
writable=FALSE") des déclencheurs.
-
bool connectWindow::triggerEvaluation ( std::string& fieldName, QString& previousValue, QString& newValue, entry* mask, QWidget* parent = NULL ) :
permet de déclencher l'exécution d'un déclencheur. Retourne "
true" ou
"
false" selon, soit l'execution correcte du déclencheur, soit l'erreur
d'exécution ou bien l'abandon de l'opérateur au sein du programme interactif
éventuellement déclenché ...
- "fieldName"
permet d'indiquer quel champ est concerné par le déclenchement souhaité. La
valeur référencée par cette variable peut avoir changé au retour d'exécution du déclencheur, ce qui
indiquera au programmeur que d'autres champs du masque (dont les noms seront alors présents dans la variable "fieldName") auront été impactés par l'exécution
du déclencheur. Il pourra alors être éventuellement judicieux de générer, au sein du programme, un
rafraîchissement d'affichage afin d'offrir à l'opérateur
la visualisation des modifications opérées.
-
"previousValue"
permet de renseigner à destination du déclencheur la valeur du champ avant son déclenchement
(cette valeur sera passée en entrée standard de la commande de
déclenchement et pourra donc être utilisée par celle-ci, si besoin est). Cette valeur est référencée par "%fieldName" au sein de la définition du déclencheur.
-
"newValue"
permet de référencer la nouvelle valeur de champ soumise à validation (référencée par "%this"
au sein de la définition du déclencheur) et, au retour de l'exécution du
déclencheur, référencera la valeur alors validée (donc : éventuellement
modifiée ou remplacée) par l'exécution du déclencheur.
-
"mask"
permet de disposer (pour utilisation ou modification) de l'ensemble des
valeurs d'attributs du masque d'écran lors de la définition (par la
syntaxe "%attributName") et lors de l'exécution du déclencheur (par utilisation du contenus de ces attributs ainsi référencés).
-
"parent" permet (si renseigné) de référencer la fenêtre appelante dont hériteront toutes les fenêtres éventuellement générées
lors de l'exécution du déclencheur (notamment lorsque celui-ci est interactif
ou bien lorsqu'il échouera avec un message sur sa sortie erreur - "stderr").
Il convient d'ouvrir selon le besoin un ou plusieurs contextes de définitions de
déclencheurs (par exemple, contexte des déclencheurs sur l'édition des
champs du masque de saisie et contexte des déclencheurs sur leur
sauvegarde au sein de l'annuaire).
Le contexte courant actif sera le dernier qui aura été appelé. Pour
changer de contexte, il suffit donc, à tout moment, de rappeler celui
souhaité, cela par le biais de la méthode : "connectWindow::
setTriggers(context, description)".
La chaîne de caractères de description servira simplement à
donner un titre à la fenêtre d'édition des déclencheurs correspondants
lorsque cette dernière sera ouverte.
La première ouverture d'un contexte donné récupère dans l'annuaire LDAP
toutes les définitions qui y sont éventuellement déjà stockées pour le
nom du contexte en question. Tout rappel ultérieur à ce contexte ne
fera ensuite plus du tout appel aux données de l'annuaire, cela jusqu'à
un éventuel "connectWindow::
resetTriggers()" de tous les contextes déjà ouverts.
Il convient ensuite d'insérer
dans le contexte courant tous les noms de champs susceptibles
d'acceuillir de nouvelles définitions de déclencheurs ("connectWindow::
insertTriggeredField()"). En pratique, il s'agira par
exemple de la liste de l'ensemble des champs définis au sein du masque de saisie de
l'interface.
Ainsi, lorsque cela est souhaité, par exemple sur activation d'un menu "
menu d'extension / édition des déclencheurs d'éditions" défini au sein de l'interface graphique, la fenêtre d'édition est ouverte ("connectWindow::
openTriggersForm()") sur le contexte courant de déclencheurs.
Dans cette fenêtre, si elle a été appelée en écriture, l'opérateur peut
éditer, modifier ou supprimer les définitions souhaitées pour tout
champ de la liste affichée (liste initialisée par appels successifs de "connectWindow::
insertTriggeredField()"). A la fermeture de cette fenêtre d'édition,
l'opérateur aura l'opportunité de sauvegarder (ou non) dans l'annaire le
nouveau contexte ainsi défini qui deviendra alors immédiatement opérant.
Ensuite, sur chaque action faisant l'object d'un contexte activé (édition pour le contexte d'édition,
sauvegarde pour le contexte de sauvegarde, ... en fait, celui qui est actif) sur l'un quelconque des
champs d'affichage de l'interface graphique, vérification sera faite si une
définition de déclencheur existe pour ce champ concerné par l'action et, si tel
est le cas, l'action effectuée (saisie, sauvegarde ou
affichage...) engendrera (voire : sera conditionnée par le résultat de) l'exécution de la
commande système
définie dans le déclencheur du champ : ("connectWindow::
triggerEvaluation()").
Ainsi, dans cet exemple, sur saisie de l'attribut "
uid", l'attribut "
homeDirectory" sera mis à jour en temps réel sur le masque de l'interface graphique, ceci avec la valeur fixe "
/tmp/" suivie de la valeur déjà contenue par l'attribut "
uid" en cours de saisie ...
Remarque : Pourquoi "%this" plutôt que "%uid" dans une telle définition ?
Car "
%uid" représente la
valeur qui précède la frappe au clavier ayant déclenché l'exécution du déclencheur (argument : "
previousValue"), alors que "
%this" représente la valeur après frappe au clavier ayant réveillé le déclencheur (argument : "
newValue").
Ainsi, l'utilisation de "%uid" plutôt que de "%this"
dans la définition d'un tel déclencheur provoquerait-elle au sein de l'attribut "homeDirectory" résultant l'absence
systématique du dernier caractère de la valeur en cours de saisie dans
le champ "uid" !...
Depuis la
version 1.8.2 (20110805) de la classe "
connectWindow", le caractère '
|' (pipe) est
utilisable dans la définition des commandes de déclencheurs, permettant ainsi de chaîner des processus.
Exemple de définitions de déclencheurs d'édition au sein de l'interface "personFrontend" :
- Déclencheur de l'attribut "sn" = $(%loginShell=echo /bin/sh) $(%uid=echo %this | tr -s [:blank:] .) $(%mail=echo %uid@$(getAttribute --domain %dn --name mail | sed s/^.*@//)) $(%homeDirectory=echo /home/%uid) %description=echo %this
- Déclencheur de l'attribut "uid" = $(%homeDirectory=echo /home/%this) %mail=echo %this@$(getAttribute --domain %dn --name mail | sed s/^.*@//)
Remarque 1: Les
déclencheurs d'édition définis dans cette GUI ne sont pas récursifs
(contrairement aux
déclencheurs sur sauvegarde) ; par conséquent, ici, la modification
d'un attribut tiers ne
déclenche pas les propres éventuels déclencheurs de celui-ci. Cela
permettra de laisser une certaine latitude à l'opérateur dans l'édition
de ses différentes valeurs de données.
Remarque 2: La syntaxe des "$()" juxtaposés permet ici d'implémenter le ";" du Shell Unix ...
