Moi en tout cas, c'est ce que j'aimerais mais après avoir lu le premier message, je vois que non. Chose que je trouve dommage parce que j'ai très rarement besoin de savoir ce que je fais sur la largeur mais plutôt sur la hauteur.
Après l'aperçu en temps réelle, n'était aucunement dans la ZEP initiale ! Il a été rajouté plus tard, car ça a été évoqué ! Et, il me semble qu'il a été dit, quelque part, que ce n'était pas la priorité ultime, alors bon.. Mais si c'est réellement un besoin ultime et qui se fait plébisciter pourquoi pas !
Je suis désolé mais revoir entièrement un éditeur ou apporter 3 évolutions, je ne met pas ça sur le même pied. Je n'ai pas dis que ça ne demandait pas du boulot.
On aurait pu partir sur des tickets GitHub mais on n'aurait pas eu les 5 pages de débats !
Je pense que l'on devrait écarter l'aperçu en temps réel de cette ZEP. Si on veut du temps réel, il faudrait sûrement des websockets, c'est-à-dire des dépendances en plus sur le serveur et un programme à part. Je n'ai pas envie de bloquer cette ZEP car on n'a pas débattu sur quelles technos utiliser ou que le temps-réel bloque un développeur qui voudrait coder cette ZEP !
Après, je suis d'accord que lors du développement de cette ZEP, l'intégration du temps-réel plus tard doit être prévu.
Je m'excuse, j'ai réagit un peu trop à chaud avec mon 'J'adore le "que" !' ! Refroidissement du sang en cours…
Moi en tout cas, c'est ce que j'aimerais mais après avoir lu le premier message, je vois que non. Chose que je trouve dommage parce que j'ai très rarement besoin de savoir ce que je fais sur la largeur mais plutôt sur la hauteur.
Je parlais juste d'inverser droite et gauche, hein, ne prends pas peur !
Parce que taper le texte à droite pour voir le rendu à gauche, c'est pas le truc le plus naturel dans nos contrées
@Situphen : on peut pas développer le reste et intégrer l'aperçu plus tard en gardant tout dans la même ZEP ? Pourtant ça me semble logique, c'est assez de tout faire d'un coup.
@Situphen : on peut pas développer le reste et intégrer l'aperçu plus tard en gardant tout dans la même ZEP ? Pourtant ça me semble logique, c'est assez de tout faire d'un coup.
Si quelqu'un connaît les websockets (dépendances serveur + code) alors pourquoi pas.
Avec Socket.io ça se fait super facilement et rapidement.
Après côté serveur je suis plus orienté Node.js pour ces choses-là (ou PHP pour les trucs à l'ancienne), donc Python ça va être compliqué, mais ça peut être jouable s'il suffit de transformer un input pour l'envoyer.
Il y avait eu des débats à droite à gauche sur les websockets, sans que rien, me semble-t-il, n'en soit ressorti. De ce côté-là, je conseille de jeter un coup d'oeil à WAMP :
Faites gaffe avec l’aperçu temps réel ! À l'heure actuelle, dès qu'il y a un peu trop de formule mathématiques, l'affichage rame comme pas possible (c'est dû à Mathjax, ça a été reporté, on n'a pas de solution à l'heure actuelle).
Toute solution d'affichage en temps réel doit s'assurer que mettre beaucoup (mais pas trop) de math ne fait pas tout planter. Je veux dire que l'affichage en temps réel ne doit pas nécessiter beaucoup plus de calcul que celui actuel, sans quoi on ne pourra plus faire de tuto mathématiques un peu touffu (c'est déjà assez lourd avec les limitations actuelles).
C'est ce que j'ai l'habitude d'utiliser, tout simplement. Après ça ou autre chose, peu importe. Après ça apporte pas grand chose de plus que d'utiliser des WS directement, à part des fallbacks/polyfills et quelques raccourcis…
Les fallbacks ça peut être franchement pas mal, ça permet de toucher des navigateurs plus anciens (voire certains navigateurs mobiles exotiques ?) pour un coût complètement nul.
Dans 90% des cas c'est l'implémentation websocket qui sera utilisée, mais nous on n'en fiche, c'est le même code côté serveur et client pour les deux, donc autant en profiter (et SockJS / Socket.io même combat là-dessus).
Après, j'étais resté là-dessus mais comme je disais ça date un peu et sans doute que socket.io a évolué. Mais tout le monde s'accordait (à l'époque) à dire que l'implémentation de SockJS était plus aboutie, notamment à cause des sticky sessions (si mes souvenirs sont bons).
Après pour l'implémentation Python, je laisse les experts parler mais il semblerait que dans les deux cas (socketio / SockJS) il faille passer par Tornado. Qui, il semblerait (encore une fois j'émets des réserves, Python c'est pas franchement mon monde) s'intègre assez bien avec nginx/Django.
Voilà typiquement le problème : ça dévie et aucun consensus sur la techno à utiliser n'émerge.
Je suis partisan d'améliorer simplement l'éditeur : aperçu AJAX simple avec clic sur un bouton, ajout de quelques bouton/menus utiles (moi j'aimerais bien un menu avec des caractères spéciaux et accentués et un bouton pour le code inline)
Pourquoi plutôt WAMP que des websockets (brutes) ?
Je ne suis pas un expert et m'y connais bien moins que toi, mais je pense que WAMP fournit une surcouche appréciable aux WS brutes. On travaille directement avec un système de messages, à l'image de signaux Django ou Qt.
Oui. Où faudrait-il en parler et centraliser tout ça ?
Javier
Voilà typiquement le problème : ça dévie et aucun consensus sur la techno à utiliser n'émerge.
Thunderseb
Le mieux serait peut-être d'ouvrir un sujet à ce propos. L'éditeur commence à poser la question du temps réel, les notifications également… Il ne coûte pas grand chose de commencer à réfléchir à la question.
Je créerais bien le sujet, mais n'ayant pas beaucoup de recul sur la question, mon message va se résumer à "On veut du temps réel : on fait comment ?".
EDIT (pardon Vayel j'ai zappé ton message) : en l'occurrence pour une preview Markdown je vois pas trop l'intérêt de passer par un "protocole" complexe. Ca introduit un overhead qui me semble inutile.
T'as une ws ouverte sur un path, tout ce qu'on lui envoie dedans elle le convertit en MD, et basta
T'as une ws ouverte sur un path, tout ce qu'on lui envoie dedans elle le convertit en MD, et basta
En HTML plutôt ?
C'est vrai que WAMP est un peu overkill ici, mais il peut être judicieux de parler d'une solution qu'on pourrait facilement utiliser partout où le temps réel est requis, non ?
Je propose que vous parliez des technos utilisées dans un sujet à part pour que celui-ci se concentre sur l'amélioration de l'éditeur.
Si lors du développement de cette ZEP, on est arrivé à un consensus sur les technos utilisées et que quelqu'un sera motivé pour mettre ça en place, on pourra faire du temps réel. Sinon, on restera sur de l'AJAX au clic d'un bouton !
Si lors du développement de cette ZEP, on est arrivé à un consensus sur les technos utilisées et que quelqu'un sera motivé pour mettre ça en place, on pourra faire du temps réel. Sinon, on restera sur de l'AJAX au clic d'un bouton !
Si lors du développement de cette ZEP, on est arrivé à un consensus sur les technos utilisées et que quelqu'un sera motivé pour mettre ça en place, on pourra faire du temps réel. Sinon, on restera sur de l'AJAX au clic d'un bouton !
Ce qui serait dommage c'est de bloquer cette ZEP car on n'est pas arrivé à un consensus pour le temps réel !
C'est le but de la ZEP de spécifier les choses justement. Après si on a un développeur qui compte la prendre en charge et connais déjà tout ou partie des solutions il peut aussi les mettre en avant
Je vous propose un truc, c'est de pouvoir agrandir l'éditeur en plein écran (cad la fenêtre du navigateur comme on fait pour la lecture zen mais qui occupe 80% de la page)
Comme ça: (avec l'icone en plus et la prévisualisation aligné)
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
Refroidissement du sang en cours…
