Notifications

Ewt génère des notifications en fonction des actions de l'utilisateur. Chaque notification correspond à une exécution d'un script, pour autant qu'un script de traitement soit déclaré dans la section notifications du fichier de config.

Exemple de notifications définies dans le fichier de config:

<notifications>
  <notification name="doc-open:before">initLayout</notification>
  <notification name="doc-save">logChanges</notification>
</notifications>

D'une manière générale, les notifications sont toujours envoyées après une action de type "ajout" ou "création", et toujours envoyées avant une action de type "suppression". Ceci dit, il est également possible de forcer l'exécution avant ou après action en ajoutant un suffixe :before ou :after au nom de la notification (par exemple doc-open:before). En l'absence de suffixe, le moteur lance la notification selon le principe évoqué au début de ce paragraphe (voir descriptions des notifications ci-dessous).

Il est possible d'obtenir des infos de contexte sur l'action à l'origine de la notification depuis le script exécuté au moyen de la variable $$.notification.

Annulation d'action

Un script déclenché par une notification :before a la possibilité d'annuler l'action demandée par la commande. Cela permet par exemple de bloquer la réalisation de certaines actions telles que des suppressions de tuples, des fermetures ou des suppressions de dossiers, des fonctions d'administration, etc.

Pour annuler une action depuis une notification :before, il suffit d'appeler la méthode $thread.abortNotifiedAction().

Une autre possibilité, moins propre, consiste à déclencher une exception. Cela mettra fin à l'exécution du script et interrompra l'action.

Notifications gérées par Ewt

app-admin

Déclenchement d'une fonction d'administration via l'action admin.

En l'absence de suffixe before ou after, la notification est envoyée après l'exécution de l'action.

app-reset

Reset de l'application.

En l'absence de suffixe before ou after, la notification est envoyée après l'exécution du reset.

app-init

Initialisation de l'application.

Cette notification ne gère aucun suffixe. L'initialisation est toujours déclenchée après le chargement complet de l'application.

app-setlocale

Changement de la locale pour la session courante.

En l'absence de suffixe before ou after, la notification est envoyée après le changement de style.

Le script reçoit les valeurs $.oldLocale, $.oldLanguage, $.newLocale et $.newLanguage.

app-setstyle

Changement de la feuille de style.

En l'absence de suffixe before ou after, la notification est envoyée après le changement de style.

Le script reçoit les valeurs $.oldStyle et $.newStyle.

doc-addtuple

Ajout de tuple à un dossier.

En l'absence de suffixe before ou after, la notification est envoyée après l'ajout du tuple.

!!! "note" Groupes alias

La notification n'est envoyée que pour le groupe sur lequel porte 
l'action. Les éventuels autres groupes qui sont basés sur la même table 
en base de données (c.-à-d. les groupes alias) ne seront pas notifiés.

doc-arrange

Modification de paramètres d'arrangement (tri, filtre ou pagination de groupe).

En l'absence de suffixe before ou after, la notification est envoyée après la modification d'arrangement.

doc-change

Modification de valeurs dans un dossier. La notification doc-change est déclenchée lors des actions qui modifient un dossier, à savoir les actions save avec modification de champs, setState, addTuple et delTuple.

En l'absence de suffixe before ou after, la notification est envoyée après la modification des données dans le dossier.

Au niveau de la séquence de déclenchement des notifications, la notification doc-change est systématiquement exécutée avant la notification native associée à l'action, c'est-à-dire avant le doc-save, le doc-addtuple, le doc-deltuple, le doc-leavestate ou le doc-enterstate, que ce soit lors du traitement before ou lors du traitement after.

La variable $$.notification reprend sensiblement la même forme que la notification native de l'action invoquée.

Action et Command

Le map $$.notification contient deux références à l'action:
$$.notification.action et $$.notification.command.action.

$$.notification.action indique l'action qui déclenche la notification. Cet élément peut être utile au script déclenché par doc-change pour savoir quel type d'action est à l'origine de la notification.

$$.notification.command.action indique l'action invoquée par le client. Il faut garder à l'esprit que certaines actions entraînent implicitement d'autres actions. Par exemple, une action close entraîne automatiquement un save, qui lui-même déclenche différentes notifications (doc-change et doc-save). Dans ce cas, la propriété $$.notification.command.action aura pour valeur close alors que la propriété $$.notification.action aura la valeur save.

Notons au passage que les propriétés $$.notification.action et $$.notification.command ne sont pas systématiquement renseignées. Par exemple, les notifications déclenchées par un traitement automatique (par exemple la notification trash-clean) n'ont pas de proriété $$.notification.action. Les notifications déclenchées lors d'un thread non lié à une requête client (par exemple le scheduler) n'ont pas de propriété $$.notification.command.

doc-clone

Duplication de dossier.

En l'absence de suffixe before ou after, la notification est envoyée après la duplication du dossier.

Attention, les notifications doc-clone:before et doc-clone:after sont adressées toutes les deux au dossier source. Dans le cas du doc-clone:after, l'identifiant du dossier créé est transmis au moyen de la propriété newDocId passée au paramètre du script.

doc-close

Fermeture de dossier.

En l'absence de suffixe before ou after, la notification est envoyée avant la fermeture du dossier (mais après l'enregistrement des données).

doc-create

Création de dossier.

En l'absence de suffixe before ou after, la notification est envoyée après la création.

doc-delete

Suppression de dossier.

En l'absence de suffixe before ou after, la notification est envoyée avant la suppression (mais après l'enregistrement des données).

doc-deltuple

Suppression de tuple.

En l'absence de suffixe before ou after, la notification est envoyée avant la suppression (mais après l'enregistrement des données).

!!! "note" Groupes alias

La notification n'est envoyée que pour le groupe sur lequel porte 
l'action. Les éventuels autres groupes qui sont basés sur la même table 
en base de données (c.-à-d. les groupes alias) ne seront pas notifiés.

doc-enterstate

Notification envoyée lorsqu'un dossier arrive dans un état donné. La notification peut être conditionnée au moyen des suffixes :before et :after. Si aucun suffixe n'est spécifié, la notification doc-enterstate correspond à doc-enterstate:before.

Le script a la possibilité d'annuler le changement d'état. Voir Annulation d'action.

doc-leavestate

Notification envoyée lorsqu'un dossier quitte un état donné. La notification peut être conditionnée au moyen des suffixes :before et :after. Si aucun suffixe n'est spécifié, la notification doc-leavestate correspond à doc-leavestate:before.

Lors d'un changement de statut, les notifications doc-enterstate et doc-leavestate sont séquencées ainsi:

• doc-leavestate:before
• doc-enterstate:before
• doc-leavestate:after
• doc-enterstate:after

Une interruption de script est possible à la demande du script depuis les notifications doc-leavestate:before et doc-enterstate:before. Voir Annulation d'action.

doc-open

Ouverture de dossier.

En l'absence de suffixe before ou after, la notification est envoyée après l'ouverture.

doc-save

Sauvegarde de données de dossier.

En l'absence de suffixe before ou after, la notification est envoyée après la sauvegarde des données dans le dossier.

La variable $$.notification donne des informations de contexte sur le modèle et le dossier concerné, ainsi que le nombre et le détail des modifications de valeurs de champs.

Exemple de valeur de paramètre $$.notification (la forme du paramètre peut varier selon l'action):

{
    "action": "save",
    "name": "doc-save",
    "params": {
        "docId": 15,
        "modelName": "venteEchange",
        "modificationsCount": 1,
        "modifications": [
            {
                "newValue": 13,
                "oldValue": 12,
                "context": {
                    "modelName": "venteEchange",
                    "docId": 15,
                    "groupName": "info",
                    "tupleId": 15,
                    "field": "heureSolde"
                }
            }
        ]
    },
    "command": {
        "action": "save",
        "params": {},
        "context": {}
    }
}

Pour la gestion des modifications sur le dossier, voir également doc-change.

Note

Ewt permet d'avoir plusieurs dossiers ouverts à la fois. La commande de sauvegarde peut par conséquent concerner plusieurs dossiers à la fois. Dans ce cas, Ewt déclenche autant de notifications doc-save qu'il y a de dossier ouvert. Chaque évaluation de script reçoit des informations de contexte personnalisées via la variable $$.notification.

doc-setview

Changement de la vue pour un dossier.

En l'absence de suffixe before ou after, la notification est envoyée après le référencement de la nouvelle vue, pour autant qu'elle soit possible.

gen-output

Génération de l'arbre de sortie. La notification est envoyée juste avant que le moteur n'entame la génération de l'arbre de sortie. Il est possible de court-circuiter la génération de l'arbre en forçant la réponse.

Attention, si l'application est configurée avec un documentMode "multi", le script est toujours évalué hors contexte de dossier. Si l'application est configurée avec le mode single, le script est évalué dans le contexte du dossier ouvert, à condition bien entendu qu'un dossier soit ouvert. Dans le cas contraire, le script est évalué en-dehors de tout contexte.

incoming-get-request

Déclenché lorsqu'une requête de type GET arrive au moteur. Le nom peut être suffixé pour limiter la notification à une servlet en particulier. Par exemple, pour limiter la notification au servlet web, on notera incoming-get-request:web. En l'absence de suffixe, la notification sera déclenchée pour toutes les servlets.

Les suffixes utilisables sont :web ou :rest.

incoming-post-request

Déclenché lorsqu'une requête de type POST arrive au moteur. Le nom peut être suffixé pour limiter la notification à une servlet en particulier. Par exemple, pour limiter l'événement au servlet web, on notera incoming-post-request:web. En l'absence de suffixe, la notification sera déclenchée pour toutes les servlets.

Les suffixes utilisables sont :web ou :rest.

on-style

Notification déclenchée lorsque l'application est affichée au moyen de la feuille de style indiquée en suffixe. La notification s'utilise toujours avec une notation du genre on-style:somestyle, où somestyle désigne un style défini au niveau de la section <styles> du config.

Lorsqu'une telle notification est déclarée, le moteur invoque le script indiqué juste avant la génération de l'output.

Attention, le script est toujours évalué hors contexte de dossier.

task-error

Notification envoyée lorsqu'une tâche du scheduler déclenche une exception non traitée.

task-overlap

Notification envoyée lorsqu'une tâche du scheduler est planifiée pour s'exécuter avant la fin de l'exécution précédente.

trash-clean

Notification envoyée lorsqu'un dossier est supprimé de la corbeille. La notification est envoyée lors d'un nettoyage manuel par l'utilisateur et lors du nettoyage automatique par le moteur.

La notification est envoyée avant la suppression, ce qui laisse à l'application la possibilité d'abandonner la suppression au moyen de la méthode $trash.abortClean. Il est recommandé d'invoquer également la méthode $trash.extendEOL afin de reporter la suppression de l'entrée, sinon la notification sera renvoyée lors du prochain contrôle.