Améliorer l'éditeur de texte du site

Bonjour à toutes et à tous !
Je trouve (et c'est personnel) l'éditeur pour écrire des tutoriels peut pratique, car il n'y a pas de retour visuel en direct à moins d'enregistrer… Une perte de temps je trouve (là encore c'est personnel !!).

Je ne sais pas si vous connaissez Grafikart, mais pour la nouvelle version de son site, il a réalisé un éditeur de texte pour site web incroyable : https://github.com/Grafikart/JS-Markdown-Editor

Et je me demandais si il était possible d'envisager quelque chose de la sorte sur le site ?
Merci de vos retours!

C'est envisagé, il y a même une zep à ce sujet où il faudrait plutot rapporter les idées.

Rendre le markdown dans une zone d'aperçu en asynchrone n'est pas si compliqué mais suppose qu'on a avancé sur la question des API (autre zep en cours).

Apres le coté WYSIWM est un peu plus complexe à gérer. Entre autre parce que ça suppose que tu as un parseur markdown coté client (en JS) pour analyser le texte et rendre les morceaux. Or ce parseur aura forcément un comportement légèrement différent de celui coté serveur. J'ai peur qu'on aille au devant de bug pénible comme des éléments de syntaxe ou des corner case qui sont parsé d'une façon sur le client qui est différente de celle coté serveur.

En tout cas tout ça est depuis longtemps envisagé mais on manque de main d'oeuvre pour avancer vite là dessus.

Pour info, Grafikart a basé son éditeur sur CodeMirror pour la partie gauche (le côté où on tape le code MD). Et donc, le soucis que l'on a depuis toujours c'est que ZdS a son MD spécifique, il faut donc étendre l'outil sur lequel on se basera.

Autre soucis : sur ZdS l'utilisation de l'éditeur sera différente de celle faite sur Grafikart : sur ZdS on va le charger sur toutes les pages, il faudra donc l'optimiser pour ne pas charger 1Go de JS/CSS par page.

Je pense que partir sur la base de Graf' (avec qui je bosse un peu en ce moment) est une mauvaise idée. On en a déjà parlé en privé et le fait est que Graf est parti sur la gem Markdown de Github et donc il a beaucoup plus de facilité que ZdS pour trouver des outils adaptés à tous niveaux.

Ah mais je proposais juste une fonctionnalité équivalente pas d'implémenter son éditeur dans le site ! De plus je pense que pour les commentaires, le textarea est plus pratique !

De plus je pense que pour les commentaires, le textarea est plus pratique !

Tu parles de quels commentaires ? Sur les articles et tutoriels ?

Bah disons que je distingue deux parties sur le site.. Sous les tutos, les articles et dans les formus -> textarea comme celui que j'utilise actuellement et pour les tutos et articles un éditeur un peu plus poussé !

Je suis assez d'accord avec cette dernière affirmation. On n'a pas besoin d'un truc de la mort pour les fora. Pour la rédaction d'article/tuto ça se justifie un peu plus.

Par contre ça peut être pénible niveau code de maintenir deux éditeurs différents. A la limite, pour moi, l'éditeur devrait être le même, la seule différence que je verrais c'est le rendu "en direct" sur la droite qui pourrait être affiché par defaut lorqu'on édite un tuto et qui ne serait pas affiché sur le forum.

Mais l'éditeur en soit, la zone ou on rédige le texte, doit être le même pour éviter les doublons.

Moi après je propose une idée qui me parrait judicieuse, comment ça se gère derrière moi je ne sais pas.. Mais je pense que pour la rédaction de tutoriels ou d'articles (qui sont enfaites des mini-tutos) quelque chose d'un peu plus poussé que ce que l'on a actuellement serait beaucoup plus pratique et faciliterais grandement la rédaction !
Je dit juste ce que je pense, à vous de juger utile ou pas !

Je pense qu'on est tous d'accord sur le fait que l'éditeur peut et doit être amélioré. On ne critique pas ta proposition, on discute, comme de tout ici, et chacun donne son point de vue. Mon point de vue n'a pas spécialement plus de valeur que le tiens.

Personnellement je réagissais surtout à la proposition d'éditeur différenciés forum/tuto où il me semble que ce n'est une option que si ils ont en commun une large partie de code car maintenir deux éditeurs sera une perte de temps importante et une plaie au niveau des bugs.

BTW, de toute façon il y a déjà une ZEP au sujet de l'éditeur. C'est surtout là bas que la discussion devrait avoir lieu. Je t'invite donc a participer directement à ce niveau. Enfin je pense que si le sujet n'avance pas vite c'est surtout qu'on manque de main d'oeuvre coté dev front et que ceux qu'on a on déjà des taches plus urgente pour le site. Mais je ne doute pas que ça arrivera un jour

Ce passage m'interesse :

quelque chose d'un peu plus poussé que ce que l'on a actuellement serait beaucoup plus pratique et faciliterais grandement la rédaction !

A quoi tu penses ?

J'ai essayé de rédiger un tutoriel il n'y a pas si longtemps de ça… Je me suis perdu entre les chapitres, les parties, les extraits.. De plus il faut rédiger puis envoyer pour voir le résultat, et l'addition de tout ça commence à me décourager de rédiger mon tutoriel sur l'aéronautique… Il faudrait une preview du document en live, et une coloration syntaxique… Pour la composition des tutoriels, (selon moi) il devrait y avoir :

• Une introduction
• Une Première partie
  • Une introduction
  • Un premier "extrait"
    • Le texte décomposé en chapitres
  • Un deuxième extrait
    • […]
  • Une conclusion de la première partie
• Une seconde partie
  • […]
• Et enfin une conclusion finale

Je ne comprend pas trop l'intérêt de mettre une introduction à chaque début d'extrait, ou il faudrait la rendre facultative…
HS : c'est moi ou les listes à puces ne fonctionnent pas ?

HS : c'est moi ou les listes à puces ne fonctionnent pas ?

Il faut un saut de ligne entre la fin d'un paragraphe et le début de la liste :

• test 1
• test 2

1
2
3
4

Il faut un saut de ligne entre la fin d'un paragraphe et le début de la liste :

- test 1
- test 2

Corrigé, merci !

A l'heure actuelle le decoupage est le suivant

• Partie I
  • Chapitre A
    • Extrait 1
    • Extrait 2
    • Extrait n
  • Chapitre B
    • Extrait 1
    • Extrait 2
    • Extrait n
• Partie II

etc

Les intros et conclusions sont possibles mais facultatives dans Parties et Chapitre. Il n'y en a pas dans Extrait.

Ah bah je viens de voir que mon idée est exactement celle proposé dans la ZEP, c'est a dire des extraits qu'on rédige et qu'on place comme bon nous semble dans des conteneurs qui contienent si necessaire intro et conclusion :

• Conteneur principal
  • Conteneur Partie 1
    • Extrait
    • Extrait
    • Extrait
• Conteneur Partie 2
  - Extrait
  - […]

Bref je vais pas m'attarder dessus, tout est bien plus détailler dans la ZEP, mais en gros je rédige un extrait sur l'histoire de l'aéronautique, puis j'ai envie de rédiger sur les moteurs.. J'ai ensuite deux extraits que je peux placer dans les conteneurs que je veux, un peu comme des cartes que l'on place dans des catégories !

La prévisualisation en temps réel est pour moi totalement superflue. Mais ce qu'il faudrait c'est une prévisualisation en AJAX, qui évite de recharger la page, et de perdre le scroll du textarea (très pénible quand on rédige un tuto et qu'on veut rapidement voir si la modif effectuée marche bien).

Je suis assez d'accord. Et comme précisé, ça poserait de gros problèmes :

• Soit la prévisu temps-réel est effectuée côté client => deux libs à maintenir, ce qui est un peu débile

• La prévisu est effectuée côté serveur et utilise le zMarkdown existant via un appel API => le serveur va se retrouver inondé de requêtes inutiles (même si on debounce les appels API côté client)

La seule solution technique qui me paraîtrait ménager la chèvre et le chou serait :

Un serveur websockets le plus léger possible (node, vertx, netty, …) qui sait faire tourner zMarkdown (le serveur sait faire tourner du Python : SimpleWebSocketServer, Jython, …) qui se contente de communiquer à travers des websockets et qui est "détaché" du serveur principal de ZdS.

Je veux bien faire ça avec Vert.x ça devrait pas me prendre bien longtemps, par contre je ne pense pas que le jeu en vaille la chandelle.

A terme pouvoir avoir un aperçu a la demande serai tout de même pratique. Pour autant ce n'est peut être pas pressé, d'autant qu'a terme, même si il y aura un wrapper Python, l'objectif est de virer python-zmarkdown et de n'utiliser que Pandoc. Si un tel service est mit en place, il faudrait que ce soit prévu.

C'est pas bien compliqué de faire un POC avec vert.x d'update temps-réel via websocket. En s'inspirant fortement de ce qu'a fait firm1 avec ZestEditor.

Je peux essayer et pousser ça sur un repo.

Done pendant la pause dej', c'était d'une simplicité enfantine à partir du code de firm1.

C'est assez lent par contre, ça reste à optimiser et à faire turbiner tout ça, avec un cache bien puissant, en écrivant le module Vert.x directement en Python et pas en Groovy, etc. Mais pour un POC c'est plutôt pas mal.

Je pousse le POC ce soir en rentrant sur un repo Github.