Ajout de HTML et JS dans le contenu

TL;DR : Le but de cette mini-zep est de produire un proof of concept de l'insertion de code JS et HTML dans le contenu et ainsi de permettre de faire des premiers tests de contenu augmentés et dynamique. Il nous manque actuellement un dev JS capable de produire ce premier type de contenu.

Contexte

Le contenu de zds est relativement statique. Ça fait longtemps que je milite pour introduire des animations ou modules interactifs. L'arrivé d'une semaine thématique sur Rosetta et le système solaire me donne l'occasion de lancer ça, mais le timing va être serré.

Le besoin

Dans le sujet cité, Eskimon a soumit l'idée de proposer une simulation de la gravitation. C'est ce que nous souhaiterions implémenté. Nous avons donc besoin que quelqu'un fasse cette simulation en JS.

C'est le premier besoin. Il nous faut un dev JS

Les contraintes front

Pour cette première version, nous allons devoir faire simple. Voici les contraintes que nous allons devoir imposer :

• Un code simple et efficace, il n'est pas question de tuer les navigateurs des lecteurs.
• A priori aucune lib JS d'accessibles autre que celles déjà utilisé par le site (matjax & jquery a priori)
• Un dev en quelques semaines pour être pret pendant la semaine thématique.
• Une interface simple et un rendu propre.

Pour vous aider, deux exemples ont été proposé comme base :

• Un exemple complet et correct de simulation mais trop complexe a utiliser
• Un exemple plus joli mais innexact niveau physique

Probablement qu'un mix des deux serait une bonne idée. Ou un autre exemple sur le net, peut importe.

Travail coté back

Actuellement le site n'est pas prévu pour autoriser ce genre de contenu. Mais cela sera interessant a long terme. Le but n'est pas a court terme d'autoriser tout le monde à injecter du JS dans leur contenu mais de commencer par faire une première expérimentation.

A priori chaque tutoriel et article se verrait attribuer d'un drapeau dans la base de donnée pour indiquer si ce contenu est autoriser à contenir du JS. Ce flag serait inactif par defaut : les auteurs ne pourront pas introduire de JS. L'activation de cet élément sera fais a la demande et au cas par cas apres un tri très strict des demandes par un staff ou admin du site. Dans un premier temps, limité a quelques articles de tests pour observer les réactions des membres et comment c'est reçu par la communauté.

Cette partie, lié à Django, serait prise en charge par firm1

Si le flag est activé, le parseur markdown détecterait un balisage particulier délimitant du code JS qui serait alors injecté en sortie.

Je me chargerais de la partie markdown.

Le coté "inactif par défaut", "activé pour des personnes des personnes de confiance" et la validation devraient permettre d'assurer la sécurité du contenu présenté à la communauté dans ces premières versions.

Et maintenant

Si vous êtes intéressé par la partie JS, si vous avez le temps et que vous souhaitez aider zds a avancer et innover, n'hésitez pas !

Tout avis est le bienvenue mais le but reste de mettre en place une v0 utilisable rapidement pour tester ça en pratique. Une généralisation de ce genre de contenu méritera une zep pleine et entière après vérification de l’intérêt. Les solutions ou modifications trop compliqués à court terme ne seront donc probablement pas envisagés dans cette version.

J'approuve l'idée, sous quelques réserves: Pour moi, cela doit se faire sous forme de iframe, et si possible sur un (sous)domaine à part.

L'iframe, parce ça isole du reste de la page, ce qui empêche aux petits malins de changer quoi que ce soit en dehors du cadre, et le NDD séparé, parce que si on met sur le même domaine, le script aura accès au cookies, donc potentiellement au cookie de session… Vraiment pas l'idéal niveau sécurité…

Du coup, pour moi, il faudrait un système ou l'on peut envoyer une archive, qui irait (décompressée) par exemple vers content.zestedesavoir.com/Sandhose/123456/. Ensuite, l'on peut imaginer une balise MD genre !{123456/simulation.html}, qui se transformera en <iframe src="http://content.zestedesavoir.com/Sandhose/123456/simulation.html"></iframe>.

Au niveau technique, ça doit être dans un dossier complètement à part, géré par nginx, et hyper-restreint niveau permissions. Pas qu'on se retrouve avec des scripts exécutes côté serveur

Je penses pas que l'on doive proposer un éditeur en ligne… Après, on pourra toujours proposer de voir les fichiers, et éventuellement versionner la chose, mais un IDE en ligne n'est pas une solution, parce que cela demanderait trop de temps de dev.

A voir ensuite si vous voulez fixer la taille de l'iframe, ou si l'on propose de le mettre en paramètre… Et si on injecte jQuery, ou si l'on laisse l'utilisateur faire ce qu'il veut…

On peut aussi imaginer que tous les fichiers passent à travers des outils permettant de minifier/optimiser un peu tout, histoire que cela n'impacte pas trop le temps de chargement…

L'avantage de cette solution, c'est qu'elle permettrait à l'utilisateur d'intégrer un peu ce qu'il veut, que ça soit une animation flash, ou un exemple HTML… On peut même envisager d'utiliser cette même syntaxe avec des URLs absolues, de sites type YT, Vimeo, Shelr, … Et ainsi avoir du contenu plus dynamique dans les articles / tutoriaux / posts de forum. Je sais que vous étiez contre il y a quelques temps, pour des questions d'export PDF et autre, donc à vous de voir si cette idée vous convient ou non

Sandhose

Une iframe est effectivement la meilleure idée. Et la page "iframée" dans un sous-domaine de zeste, et restriction de lecture des cookies/sessions pour ce sous-domaine.

Pour un POC j'ai plutôt envie de dire "KISS + Validation stricte" perso… Parce que si les gens ne se servent pas du bouzin ou ne sont pas plus enthousiasmé ca en fait des heures de dev de perdu…

J'étais plutot dans la vision d'Eskimon. Je comprends bien l'interet de la proposition mais :

1. ça va être plus long a mettre en place et risque de nous faire rater l'occasion présenté
2. ça complique la validation car il faut permettre aux validos de consulter le contenu uploadé.

L'idée était vraiment de faire une premiere version simple. La solution proposé a deux avantage :

1. Tres rapide a implémenté
2. Les validos verront de maniere simple et évidente le contenu injecté.

Mon but n'est pas de faire une version définitive et accessible a tout le monde, juste de faire un essai sur un ou deux articles pour voir ce que ça peut donner et comment c'est accueilli.

Hors iframe, c'est un monstre niveau sécurité… En plus, juste copy-paste de l'HTML + JS en plein milieu du message / de l'article (si j'ai bien compris, c'est ce que tu pensais ?), c'est horrible à lire…

Au pire, on peut proposer simplement d'intégrer des services en iframe, comme YouTube, Vimeo… Et un truc genre JSFiddle… Avec ça, on aurait de quoi simplement permettre d'intégrer une partie dynamique, sans presque aucun coût niveau dev (à part dans le parseur MD, peut-être), c'est sécurisé, et à priori, un contenu à une certaine URL n'est pas directement modifiable (donc possibilité de faire passer à la validation, sans que le contenu puisse être modifié par après, sans re-validation). En plus, c'est sécurisé, y'a un p'tit IDE en ligne… Et on peut faire ça avec d'autres services, comme il en existe des milliers sur le web.

Seule restriction avec ce genre de services, c'est qu'à priori, la plupart mettent leurs petit bandeau perso… A voir si c'est réellement gênant

Bah nickel si des services comme ca existe (permettant d'embarquer juste le resultat, pas toute le code et tout l'toutim), c'est juste un truc à intégrer comme les vidéos du coup ?

Si on peut empacter ça, pas de soucis je peux compléter la balise de vidéo. Encore une fois ça ne sera pas accessible à tous les auteurs mais si vous avez un service qui permet d'heberger un contenu JS non modifiable et de l'insérer facilement (comme on fait pour les vidéos actuellement), je prend.

Codepen (voir "codepen embeded") aussi permet de faire ça. Avec l'avantage de pouvoir afficher le "rendu" directement. On voit souvent ça sur les blogs de devs. Mais ça implique d'être tributaire d'un service annexe…

On est déjà tributaire de youtube, entre autre… Et là encore, c'est une expérimentation. Si on a besoin a terme d'heberger le contenu, on le fera, mais ça me plait assez pour une expérimentation

J'ai juste regardé la doc de JSFiddle pour l'instant et ça pourrait coller (facile de déduire le bout de code à insérer pour voir uniquement le résultat) et perso je me fout qu'il y ai le nom du service.

Par contre je n'ai pas vu clairement si l'auteur d'un script peut éditer le contenu de son script apres l'avoir publié. Il faudrait que le contenu soit figé pour assurer la sécurité (que le membre ne modifie pas son script apres la validation)

@Eskimon: Ouais, par exemple, cette URL d'un vieux fiddle (qui devrait te rappeler quelque chose ) donne uniquement le résultat, avec juste un bandeau au dessus… Et ça, suffit de le foutre dans une iframe (genre <iframe width="100%" height="400" src="http://jsfiddle.net/Sandhose/BcKhe/1/embedded/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>), et le tour est joué!

@Kje: Bah à priori, à chaque fois que tu sauvegardes sur JSFiddle, ça rajoute une révision, et donc ça garde les anciennes versions intactes…

Pour l'histoire d'être tributaire d'un service externe… C'est comme dire qu'on l'est par rapport à GitHub… Honnêtement, je ne pense pas qu'on doit s'en soucier réellement, du moins pas à moyen- et court-terme

@Thinderseb: +1 pour codepen

Du coup je plussoie grandement cette intégration ! Car a part le parseur on a rien a changé non ?

Du coup essayez d'intégrer ce genre de saloperies si vous voulez un test (JSFiddle en l'occurrence)

Ah ah c'est énorme, vraiment joli ! Et du coup si on peut intégrer ca on peut meme faire une interface naïve pour modifier quelques parametres (comme la gueule de l'ellipse par exemple) !! Chapeau Javier c'est super cool comme truc !

JSFiddle a l'air de faire ce qu'on lui demande, on va faire ça si il n'y a pas d'avis contraire d'ici demain.

Pour un poc, ce sera parfait.

@Eskimon : ce que j'ai fait est amusant pour un PoC mais c'est scientifiquement au ras des pâquerettes. Et c'est là que ça va devenir complexe : si on veut d'écrire l'évolution de la vitesse d'une planète en JS et utiliser rigoureusement les lois de Kepler ça va être très compliqué.

Faut voir quel est le but. Si c'est de la vulgarisation sur une thématique précise, je ne vois pas l'interet de faire un truc mega super précis.

De mon souvenir d'Encarta, l'idée c'était exactement ce que tu as fait (avec une interface pour bidouiller les paramètres). En gros tu pouvais voir l'influence de l'ellipse sur la vitesse de rotation autour du soleil par exemple. Après si tu donnais une vitesse initiale trop élevé, ta planete quittait carrément l'orbite du soleil et partait se balader. Au contraitre, vitesse trop faible et la planète s'écrasait lamentablement. Du coup tu remplaces la planete par une fusee et tu comprenais comment il fallait grosso modo faire pour quitter une orbite de planete (et maintenant je me rends compte de l'effet de fronde d'ailleurs)

C'est bien là le problème, dans mon exemple la vitesse est fixée…

J'ai pris 365 jours, y'a aucune notion de vitesse ou de moment angulaire. Et c'est là qu'il va falloir creuser si on veut faire un modèle ne serait-ce qu'un peu générique et scientifiquement "acceptable".

Là si tu regardes bien la boule verte fait le tour de l'ellipse en 365 jours, parce que j'ai fixé arbitrairement 365 jours.

En gros si tu veux rajouter Mars à mon PoC pourri il te faut :

• les caractéristiques de son ellipse (périhélie, aphélie, petit-axe)

• sa période de rotation autour du soleil

• une condition initiale par rapport à la Terre

Alors qu'on aurait aimé reposer sur les lois de Kepler pour déterminer les caractéristiques de l'ellipse, ou encore influer sur la vitesse, ou que sais-je encore :\

Bref, le plus gros du boulot c'est modéliser ce qu'a évoqué Gabbro et ça, c'est vraiment, vraiment pas évident.

@Javier : On a parlé d'une simulation du systeme solaire mais ça peut etre autre chose. Tu avais parlé d'une visualisation du trajet de Rosetta. Tu peux t'occuper d'organiser ce dev au niveau du "concentré de savoir" ? Tu peux partir de l'hypothèse qu'on intégra JSFiddle.

@Tous : Lors du rendu de JSFiddle j'hésite à n'afficher que le rendu ou les 4 onglets (html+css+js+rendu). Ce dernier cas rajoute une barre à onglet sur le cadre mais permet aux lecteur de voir le code sous-jacent (ouverture, apprentissage, etc.) et surtout permettrait aux validos de vérifier le contenu directement, sans avoir à ouvrir l'élément dans l'ide séparé (car a court terme il n'est pas possible de faire simplement un rendu différent pour l'étape de validation et pour l'étape de publication).

Tu peux pas avoir une option pour afficher l'un ou l'autre ? Car dans certains cas le code importe peu, on veut juste ajouter de l’interactivité et dans d'autres ca sert pédagogiquement.