OK
AJAX error!

Les forumsGrammalecteUtilisation de Grammalecte dans un éditeur de texte riche Wysiwyg type TinyMCE

Utilisation de Grammalecte dans un éditeur de texte riche Wysiwyg type TinyMCE

Bonjour,

Je développe tracim - www.tracim.fr… et pour l'édition "grand public" de documents, nous avons intégré un éditeur TinyMCE qui permet de saisir du code riche directement. Le problème auquel je fais face est que bien qu'ayant installé le plugin grammalecte (sur Firefox ou Chrome), je n'ai pas la possibilité de demander la correction grammaticale. Y-a-t-il qqchose à faire pour que les zones de texte type WYSIWYG soient prises en compte ? Visibilement il y a une option "zones éditables" mais ça n'a pas l'air de fonctionner dans le cas qui me concerne...

Merci pour votre aide.

p.s : si possible, j'aime autant ne pas avoir à installer/gérer une instance de gramalecte server
le 05 novembre 2018 à 18:06
Bonjour,

Si j’ai bonne mémoire, la zone d’édition de TinyMCE est bien plus qu’un simple node éditable, c’est une iframe dans laquelle est générée une page web. Donc, en gros, il faudrait que Grammalecte soit capable d’éditer directement une page web, c’est-à-dire modifier les éléments du DOM d’une page sans rien altérer par ailleurs.

Grammalecte n’est pour l’instant pas capable de faire ça. Pour l’instant, ce que fait Grammalecte, c’est ajouter au DOM les éléments nécessaires pour le panneau de correction et renvoyer le résultats des modifications au node concerné (textarea ou node éditable).

Dans une iframe, de surcroît, je ne sais pas si Mozilla autoriserait ce genre de choses.

EDIT: Il me semble qu’un plugin TinyMCE pour LanguageTool avait été créé, mais jamais fini, je crois.
le 05 novembre 2018 à 18:46
Bonjour,

Il y a aussi le problème que TinyMCE a un "contexte menu" personnalisé. Il faudrait donc non seulement surveiller les modifications et injection du DOM ET en plus ajouté au "contexte menu" de TinyMCE les fonctions de Grammalecte. Je pense pas que se soit possible facilement vu les CSP des extensions et si ça l'est ça risque de ralentir très fortement la navigation.

Le plus simple et je pense aussi le mieux pour les visiteurs est de créer un plugin pour TinyMCE qui interroge une instance de serveur de Grammalect. Par cette méthode ça permettrais que tous les visiteurs ont le correcteur sans avoir a installer l'extension Grammalecte.
le 06 novembre 2018 à 12:22
J'ai trouvé un moyen qui permet à un script sur une page d'ouvrir soit le panel de correction soit le lexicographe.
J'ai donc ouvert une branche avec les modifications nécessaires. Par contre pas le temps de faire un plugin a TinyMCE pour lancer Grammalecte (peut être qu'un simple bouton suffit ;) ).

Et nous pouvons donc avec un script sur une page web :

// Grammalecte est prêt!
// La page web peut effectuer des actions à envoyer a la webextention
document.addEventListener('GrammalecteIsLoaded', function() {
...
});

...
// Pour demander une correction sur le texte
sendToGrammalecte({"spellcheck": "salut comment ca vaa?"});
// Pour demander une correction sur un élément html
sendToGrammalecte({"spellcheck": true, "elm": elementHTML});
// Pour avoir le lexicographe sur un texte
sendToGrammalecte({"lexique": "salut comment ca vaa?"});
// Pour avoir le lexicographe sur un élément html
sendToGrammalecte({"lexique": true, "elm": elementHTML});

EDIT : Il faudrait surement donner accès a des fonctions de plus bas niveau. Dites-moi si ça pourrait servir dans votre cas, lebouquetin.
le 07 novembre 2018 à 00:51
Je suis occupé aujourd’hui et demain. Je regarderai ça vendredi.
le 07 novembre 2018 à 13:44
lebouquetin, pour test : touslesmots.com…
Permet à l’extension d'ajouter un bouton aux zones éditable de tinyMCE pour lancer le panel de correction.
Vu le nombre de manière d'instancier tintyMCE j'ai essayé de prévoir le maximum de cas mais il se peut que pour certaine zone ça n’ajoute pas le bouton.
le 10 novembre 2018 à 17:17
Je viens de voir qu’il existait un plugin bêta pour LanguageTool/TinyMCE.
github.com…
forum.languagetool.org…
le 10 novembre 2018 à 17:24
Maintenant avec les ajouts que j'ai faits effectivement ça pourrait surement intégrer un plugin. Donc il faudrait que j'ajoute un lien vers la "fonction" qui retourne les erreurs et que le plugin a place qu'il interroge un serveur il utilise cette fonction.
ça devrait être faisable relativement facilement.
le 11 novembre 2018 à 04:04
J’ai commencé à regarder, même si je n’ai toujours pas le temps de tout examiner en détail.

Remarques :
— N’était-il pas possible d’injecter un script API.js comme n’importe quel autre content-script et faire les appels directement depuis la page web ? Je présume que non, mais je demande à tout hasard, parce que trois couches intermédiaires pour communiquer entre une page web et Grammalecte, ça commence à faire beaucoup… :)
— Pas de «"use strict";» dans le script injecté ? Un oubli ?
— Vu que le script est inséré dans la page, il faut sécuriser les noms de variables et de fonctions (comme je l’ai fait dans tous les content-scripts, présumant qu’il y avait potentiel conflit avec le code des pages web).
le 11 novembre 2018 à 13:08
Le premier point : Pour l'injection du script faite comme ça c'est pour être dans le même contexte de la page et donc dans ce cas pouvoir avoir accès tinyMCE. Le début du script est l'établissement de la communication entre la web-extension et la page et la suite c'est pour le cas de tinyMCE pour lui ajouter le bouton. Cette manière d'injection du script permet en plus de pouvoir accéder au contenu de l'iframe vu qu'elle est créée par script par tinyMCE et que nous somme donc dans le même contexte (celui de la page).
Le problème du code fait actuellement c'est qu'il est vraiment pour traiter le cas de tinyMCE et que pour les autres éditeurs WYSIWYG il leur faudrait une partie spécifique.

La grande question est jusqu'où c'est le travail de la web_extension de le faire et ce que le webmaster doit mettre ?
Je m'explique vu que de mettre tinyMCE sur un site est le choix du webmaster est-ce à lui de mettre le bouton pour faire appel au correcteur (en plus ça simplifierait pas mal de code du script injecté (d'ailleurs tout le script injecté pourrait être géré par le webmaster) ;)) ? et donc faire une sorte de plugin qui communique avec la web-extension (voir si pas de web-extension ça interroge un serveur Grammalecte) ?

— Pas de «"use strict";» dans le script injecté ? Un oubli ?


Oups un oubli pour le "use script".
le 11 novembre 2018 à 14:19

IllusionPerdu :
La grande question est jusqu'où c'est le travail de la web_extension de le faire et ce que le webmaster doit mettre ?
Je m'explique vu que de mettre tinyMCE sur un site est le choix du webmaster est-ce à lui de mettre le bouton pour faire appel au correcteur (en plus ça simplifierait pas mal de code du script injecté (d'ailleurs tout le script injecté pourrait être géré par le webmaster) ;)) ? et donc faire une sorte de plugin qui communique avec la web-extension (voir si pas de web-extension ça interroge un serveur Grammalecte) ?


Avoir à surveiller un logiciel tiers est toujours pénible, donc mieux vaut prévoir une intégration facile pour le webmestre.

J’ai regardé ton code, et certains points me chiffonnent, mais j’imagine que c’est parce que tu veux ajouter quelque chose avec ça. L’identifiant ActionId n’est pas utile pour l’instant. Je ne comprends pas non plus pourquoi tu bidouilles autour des données à envoyer.

Il y a aussi

xEditorAdd.settings[sBtn]


où sBtn est potentiellement undefined.
le 12 novembre 2018 à 13:43
Pour le ActionId actuellement ce n'est pas utilisé, c'est une ouverture vu qu'il existe pas mal d’éditeur WYSIWYG ça pourrait permettre à des webmaster de pouvoir interrogé la web-extension et d’identifier à quelle question correspond les réponses de la web-extension. L'idée serait de faire une passerelle directement vers le "parseAndSpellcheck" du worker et que le webmaster puisse faire ce qu'il veut de cette réponse (servirait aussi dans le cas de tinyMCE si un plugIN complet était créé).

Pour les bidouilles autour des données je pense que tu fais référence à ce qu'il y a dans le init.js "GrammalecteEvent" c'est puisque j'ai voulu faire un accès générique car aujourd'hui c'est le cas de tinyMCE à gérer mais demain il y aura surement un autre cas ;) de plus c'est aussi à cause de l'ouverture pour les webmasters afin qu'ils puissent gérer comme ils veulent.

TinyMCE comme je l'ai dit précédemment n'est pas toujours instancié de la même manière, ce qui pose pas mal de problèmes. Personnellement je pense qu'on devrait laisser la partie communication avec la web-extension (modif du init.js et le début du event.js) et puis faire des exemples de script que le webmaster devrait intégrer s'il veut prendre en compte la web-extension et ainsi ajouté le bouton pour le correcteur).


sBtn est potentiellement undefined.


Lequel ?

Note : j'essaie de faire des tests supplémentaires ce soir.
le 12 novembre 2018 à 14:58
Bonsoir,

Déjà toutes mes excuses pour ne pas être revenu plus rapidement répondre à vos messages et tester l'extension tinymce modifiée. J'avoue que j'ai été surpris (dans le bon sens) par la réactivité sur ce forum :)

Sur le sujet de "c'st le webmestre qui est responsable de proposer tinymce", je suis d'accord, mais le texte riche dans les pages web est devenu un standard sur de nombreux outils en ligne. Sur un autre projet (un site web pour le coup, pas une application), on a une interface d'admin avec un plugin codemirror pour faire de la coloration syntaxique markdown et on a exactement le même problème : ça passe par une iframe, donc pas détecté par grammalecte.

Le mécanisme de remplacer un textarea par un iframe est relativement standard ; sachant qu'au niveau formulaires, le textarea existe toujours. Je me demande s'il n'y a pas qqchose à faire de ce point de vue pour simplifier l'intégration de grammalecte avec tous les éditeurs riches (qui s'appuient, il me semble, sur les même mécanismes).

En tout cas je vais essayer l'extension grammalecte, on verra ce que ça donne et si on peut filer un coup de main sur le JS, ça sera avec plaisir.

Le Bouquetin.
le 01 décembre 2018 à 01:08
Je n’ai pas constaté que les TinyMCE-like étaient particulièrement fréquents, bien au contraire, mais le Web est tellement vaste qu’il n’est pas surprenant que les expériences divergent.

Je ne sais pas trop ce qui est faisable pour l’instant, mais sauf mésestimation de ma part c’est loin d’être simple, si on veut manipuler la page web incluse dans l’iframe, le problème principal étant de retourner les erreurs détectées dans ladite page. Peut-être que le textarea permettra de faire une solution bâtarde pas trop compliquée. Mais bon, je suis moins compétent qu’IllusionPerdu pour manipuler le DOM, je me fais peut-être des idées, je surestime peut-être les complications.
Une chose à savoir : si vous utilisez quelque chose comme

un_node.innerHTML = "…"


ce sera rejeté par Mozilla.

Quoi qu’il en soit, en ce qui me concerne, pour l’instant, ma priorité c’est de finir le serveur de dictionnaires et de publier la version 1.0 d’ici la fin décembre.
Une fois que ce sera fait, j’aurai plus de temps à consacrer à l’interface WebExtension.
le 02 décembre 2018 à 13:45
> Je n’ai pas constaté que les TinyMCE-like étaient particulièrement fréquents, bien au contraire, mais le Web est tellement vaste qu’il n’est pas surprenant que les expériences divergent.

Je pense que tu as raison - il y a très nettement plus de cas où on utilise des textarea bruts. Là où les tinyMCE-like sont très courants, c'est sur la gestion de contenus riches, de documentation, de gestion de connaissance. Dans ces cas-là, on utilise rarement de simples textarea, et pourtant je pense que c'est un cas où il est très important d'avoir une correction orthographique et grammaticale car le texte a vocation à être pérenne.

En lisant ta réponse et en répondant à ce fil, me suis en train de me dire deux choses :

- d'une part loin de moi l'idée de "demander à ce que tu regardes". Tu as un projet et un fil conducteur, je ne m'attends pas à ce que ça changer parce que j'ai besoin de quelque chose :)
- je me demande si je ne proposerais pas un stage sur le sujet de cette intégration et éventuellement celle de language tool dans des éditeurs riches.

Merci pour ta réponse en tout cas.
le 04 décembre 2018 à 09:53

Là où les tinyMCE-like sont très courants, c'est sur la gestion de contenus riches, de documentation, de gestion de connaissance.


En effet.
Il ne faut pas croire que je n’ai pas conscience des limites de l’interface actuelle. Je me rends bien compte des problèmes. Et il est bien dans mon intention de m’en occuper un jour ou l’autre.
Ces derniers mois, LanguageTool a beaucoup travaillé sur son interface (c’était nécessaire, vu celle d’avant, à mon avis) et il sera sans doute intéressant d’aller jeter un œil sur la manière dont ils s’y prennent.

Quoi qu’il en soit, je comptais de toute façon rebosser sur l’interface de la WebExtension. Je ne promets rien, parce que JavaScript n’est pas mon domaine favori et me donne régulièrement envie de balancer mon PC par la fenêtre et d’en finir avec l’informatique, mais bon, il y a quand même certains aspects que je veux améliorer. On verra alors.
le 04 décembre 2018 à 10:45
Il y a pas mal de problème avec les tinyMCE-like vu qu'ils sont créés par script. Avec les petites recherches que j'ai faites, je pense que le mieux serait de laisser un moyen de communication avec la web-extension et de créer un plugin pour tinyMCE qui communique avec (dont c'est le webmaster qui initialisera avec son tinyMCE-like).

Ce qui est compliqué avec la web-extension c'est qu'il ne faut pas que ça interfère avec le bon fonctionnement des sites (dont le fonctionnement est très variable) et que l'usage reste simple. Un exemple simple qui pose actuellement problème c'est si le textarea est dans un "div" qui a sont overflow à hidden on ne voit qu'une petite partie du bouton ;) Ce qui complique aussi c'est certaines fonctionnalités de JavaScript ne sont pas autorisées dans les web-extension pour leur validation :s

Language-tool utilise un serveur en ligne qu'ils interrogent, ce qui simplifie un peu les choses ;) mais à d'autres inconvénients (pas d'internet pas de correcteur).

Vu déjà toutes les améliorations qu'il y a eu depuis la dernière version je pense qu'il est préférable de terminer ce qui a été commencé et de voire les améliorations de la web-extension pour plus tard ;)
le 05 décembre 2018 à 12:04

Notification par e-mail    1