OK
AJAX error!

Les forumsGrammalecteMessages pour le (Shared)Worker de la future WebExtension

Messages pour le (Shared)Worker de la future WebExtension

### Problématique : ###
Afin de ne pas faire freezer Firefox, le moteur de Grammalecte est encapsulé dans un SharedWorker.

Généralité : le Sharedworker peut aussi bien exécuter des fonctions de Grammalecte que des fonctions définies dans celui-ci.

Page d'arrière plan : il ne se pose pas de problème particulier.

Scripts de contenu :
=> il peut y avoir des actions pour plusieurs éléments
=> il peut y avoir des actions générales

Pour les autres pages, je ne pense pas qu'il y aait des problématiques supplémentaires.

### Proposition de la composition des messages envoyés aux Sharedworker ###
Il faut donc obligatoirement que ce soit un objet dont voici la description à laquelle je pense.

MessageSharedworker = {
information: {
ID: string/null, //Permet de définir l'id d'un élément DOM pour appliquer le résultat retourné null si action générale
Action: string/null //Idem que ID sauf que c'est pour identifier les actions générales
},
command:{
Name: string, //Utilisation du même nom que de la fonction appelée si c'est par exemple pour une fonction du oTokenizer utilisation de la forme Tokenizer.fonction
Argument: objet //Sous la forme {"nom1 argument fonction": valeur1, "nom2 argument fonction": valeur2}
}
}



### Proposition de la composition des messages réponse du Sharedworker ###

MessageSharedworker = {
information: {
ID: string/null, //copie du message reçu
Action: string/null //copie du message reçu
},
command:{
Name: string, //copie du message reçu
Reponse: objet //c'est simplement le return de la fonction éxécuté
}
}



Si erreur, remplir la réponse avec un objet dont la définition serait

ObjetErrreur = {
Type: string, //erreur, erreurfonction, ... //c'est afin de gérer la gestion d'erreur
Description: string/null //nécessaire si c'est une erreur qui s'affiche à l'utilisateur car c'est le message qu'il verra.
}



## Conclusion ###
Avec cette définition des messages, je pense qu'on peut pallier à tous les cas pour savoir à quoi appliquer les Messages, effectuer des actions éventuelles supplémentaires quand c'est des réponses à certaines fonctions, si c'est pour un élément DOM une action générale...

Je trouve qu'il est important de garder les même noms que les fonctions pour les command.Name, ça peut éviter de se perdre dans la chaine d'exécution.

Avec l'iframe intermédiaire si les messages ne sont pas sous cette forme, ils ne devront pas être transmis mais exécutés par celle-ci. ça pourra par exemple servir pour stocker les paramètres à appliquer pour la page.

Qu'en penses tu ?
le 11 août 2017 à 01:48
Pour les commandes au worker, ce sera un objet avec les attributs suivants :
— sCommand: string,
— dParam: objet avec les paramètres comme attributs,
— dInfo: objet avec les informations que vous voulez voir revenir dans le résultat.

Les réponses renvoyées seront de la forme suivante :
— sActionDone: équivalent à sCommand passé en entrée,
— result: résultat de l’action (tout type possible),
— dInfo: objet passé en entrée, retourné tel quel,
— bError: true|false

Si bError est true, alors result est un objet d’erreur… je ne suis pas encore sûr de ce que j’y mets, mais grosso modo le message, un type d’erreur et peut-être autre chose.
le 11 août 2017 à 13:40

Notification par e-mail    0