Produits Entr'ouvert » Godo

(je ne sais pas ce que serait "mark" et "blocks").

Sur un test rapide, je ne vois pas le problème qui a été rencontré, j'ai écrit {{ form_var_plop }} dans un champ godo et c'est bien ça que j'ai obtenu comme valeur.

mark sont bold italic et liens.
L'idée est de les interdire en sein d'une var django comme produire `{{ <em>form_var_plop</em> }}`

Pour les blocks, ne pas les ajouter à un tag django seul sur une ligne et se retrouver avec
`<p>{% if truc %}</p>`

Dans ce ticket, ou un autre, il faudra aussi voir comment traiter cette utilisation :

<ul>
 {% for whatever in form_whatever %}
 <li>{{ whatever }}</li>
 {% endfor %}
</ul>

Thomas Jund (tjund) a ouvert une pull request sur Gitea concernant cette demande :

• URL : https://git.entrouvert.org/entrouvert/godo.js/pulls/30
• Titre : WIP: JS: add support for django template syntaxe (#78225)
• Modifications : https://git.entrouvert.org/entrouvert/godo.js/pulls/30/files

Juste des réflexions:

• <a href=¨{% if ... %} {% endif %}">... pas possible dans l'éditeur sans édition du code source
• {% if .... %}<b>{% endif %} pareil

Je dirai bien qu'il faut viser une intégration pour les usages qui respectent la forme du DOM et dans ce cadre, ne pas tenter une bijection entre template Django et HTML au niveau de l'éditeur mais avoir des noeuds du DOM ```<wcs:djtag/>``` et ```<wcs:djnode/>`` qu'on maintient même dans le contenu stocké par w.c.s. (ça ressemblera un peu à Genshi https://pypi.org/project/Genshi/) et qui seront traités par le code de templating et qui ne seront possible qu'en étant du contenu et en respectant la forme syntaxique du DOM (les paires ouvrantes/fermantes).

Ça veut dire que les vieux templates ne rentreront pas automatiquement dans la nouvelle fonctionnalité, on continuera à devoirs les éditer en code source, ou les réécrire. Mais que le nouveau paradigme dissuadera de faire des choses complexes (genre éviter les conditions dans un attribut class pour changer le style, à la place avoir une structure de contrôle au dessus de toute un paragraphe ou un bout de texte).

--

Ça c'est une proposition qui reste dans l'idée de cette PR; une autre serait de faire
ça via des attributs du HTML (à la Genshi aussi donc), avoir des éléments plus fin <wcs:django-expression> pour du contenu, et des attributs html wcs:django-with="mavar monexpression|truc", wcs:django-if="form_var_foo and form_var_bar", wcs:django-for="foo in bar" pour les structures de contrôle.

Passer par des attributs sur les noeuds existants est d'ailleurs peut-être plus ergonomique que d'ajouter de nouveaux types de blocs, et pareil ça oblige l'auteur du template à respecter une certaine structure plutôt que de chercher à faire le template le plus court possible (il y a des choses naturelles comme avoir une boucle for sur un <li> ou un <tr> ou un <p>).

Juste des réflexions:

C'est bienvenue

<a href=¨{% if ... } { endif %}">... pas possible dans l'éditeur sans édition du code source

L'édition des valeurs des attributs se fait par un input, donc possible de taper du template django. La difficulté se fait au niveau du parsing du code source : ne pas baliser les tags au sein des attributs. Je soupçonne le parsing godo d'être déjà restrictif, mais pas encore testé.

{% if .... }<b>{ endif %} pareil

En effet, ne sera pas possible

mais avoir des noeuds du DOM ```<wcs:djtag/>``` et ```<wcs:djnode/>`` qu'on maintient même dans le contenu stocké par w.c.s.

Ce serait plus simple côté godo, mais ça veut dire qu'il faut un pre-rendering côté django

le nouveau paradigme dissuadera de faire des choses complexes (genre éviter les conditions dans un attribut class pour changer le style, à la place avoir une structure de contrôle au dessus de toute un paragraphe ou un bout de texte).

Là dessus, on est ok,

ça ressemblera un peu à Genshi

Merci pour la ref. je partirai bien sur un truc plus simple quand même

Ça veut dire que les vieux templates ne rentreront pas automatiquement dans la nouvelle fonctionnalité

Je n'avais de toute façon pas en tête d'être compatible avec les templates existants.

une autre serait de faire ça via des attributs du HTML

Piste super interessante. Dans cette PR, je vais exclure le cas d'usage des boucles pour les listes, trop ambitieux, PR trop lourde.
La grosse difficulté est de rester une UI compréhensible.

Merci BenJ

(je commente sur une mini-partie)

Je n'avais de toute façon pas en tête d'être compatible avec les templates existants.

Faut alors ne pas oublier d'introduire quelque chose permettant de différencier.

Et inclure dans la réflexion le chemin qui permettrait de passer d'un gabarit existant à un "nouveau" gabarit.

Une page de test est disponible à l'adresse
https://perso.entrouvert.org/~tjund/godo/test-django.html
Merci de laisser vos remarques à la suite dans ce ticket.

Je vais sur https://perso.entrouvert.org/~tjund/godo/test-django.html

• je clique dans la zone "Godo Editor"
• je clique sur {% ça insère un "{% if %}" (je ne souhaite pas nécessairement un if)
• je clique après le if pour écrire, ça sélectionne la zone "{% if %}"
• je reclique, je peux écrire un truc,
• je complète avec form_var_foo == "plop"
• je clique derrière le %}
• j'écris ça continue à écrire en rouge, ça me surprend, j'efface mes quelques lettres,
• je clique à nouveau derrière le %}
• ça semble me positionner un peu différemment
• je tape et rien ne s'affiche
• je clique sur le bouton %} en me disant que ça me sortira peut-être de ce mode, non

je clique sur {% ça insère un "{% if %}" (je ne souhaite pas nécessairement un if)

On peut mettre autre chose par défaut, si ça ne te semble pas pertinent comme exemple

je clique après le if pour écrire, ça sélectionne la zone "{% if %}"

Oui, c'est le comportement d'un tag verrouillé par l'éditeur, c'est le seul moyen que j'ai trouvé pour exclure l'insertion d'un strong ou d'un em au sein de l'élément. La sélection automatique est aussi très pratique pour appliquer un strong sur tout le tag (techniquement autour donc) parce que sinon avec l'api selection des navigateurs ce ne serait pas possible (si besoin je peux détailler).

je clique derrière le %}
j'écris ça continue à écrire en rouge, ça me surprend, j'efface mes quelques lettres,

Si le curseur est rouge, tu es dedans, s'il est noir tu es en dehors.

je clique à nouveau derrière le %}
ça semble me positionner un peu différemment

Le curseur est différent (noir certainement)

je tape et rien ne s'affiche

Tu es dans un "bloc Django virtuel" (voir explication) et ce bloc ne peut contenir qu'un seul tag django que tu as déjà saisi et rien d'autre. Parce qu'il ne faut pas se retrouver avec du contenu texte seule à la racine (qui n'est pas inclus dans une balise html)
Il faut donc aller à la ligne (avec le curseur noir) pour créer un nouveau paragraphe

Il faut donc aller à la ligne (avec le curseur noir) pour créer un nouveau paragraphe

Oui, et je vois dans mes notes https://git.entrouvert.org/entrouvert/godo.js/pulls/30#issuecomment-52882 que là j'avais insisté et vu qu'en créant un nouveau paragraphe ça passait, mais sans explication ça n'est pas évident, notamment parce qu'il n'y a pas de retour (on tape et les caractères n'apparaissent pas, point).

Aussi, à relire donc mes notes :

sur la ligne suivante je souhaiterais écrire "bonjour {% if form_var_title == "Mme" }madame{ else }monsieur{ endif }" mais le { n'est pas accessible

c'est toujours pareil.

je complète pour que ça contienne "{{ form_var_title }}" et je n'arrive pas à sortir de la zone avec la flèche droite,

ce point par contre ça va (passé le deuxième } même s'il faut encore appuyer une fois flèche droite pour "vraiment" sortir.

Pour les tags, est-ce qu'il y aurait moyen d'exclure les délimiteurs syntaxiques {%, %}, {{ et }} du contenu du noeud dans Godo ? Pour que quand on édite une directive {% if %} ou {{ foobar }} on ne puisse toucher que à "if" ou "foobar" et pas aux délimiteurs (qui ne seraient là qu'au rendu du noeud) {% / %} / {{ / }}. À charge pour Godo lors de la génération du contenu texte de re-créér les délimiteurs. Il me semble que ça contraindrait l'édition de manière plus utile.

est-ce qu'il y aurait moyen d'exclure les délimiteurs syntaxiques {%, %}, {{ et }} du contenu du noeud dans Godo ?

Oui c'est techniquement possible, ça necessite alors côté code un nouveau tag html et côté menu un nouveau bouton d'action. Mais ce serait peut-être plus clair pour l'usager :

• un bouton `+ {{`
• un bouton `+ {%`
• et un bouton `je sais pas quoi` pour celui qui permet d'être à la racine du document

d'ailleurs je suis preneur d'idées pour les icones des boutons, là dessus je sèche, et c'est surement à l'origine de quelques incompréhensions.

d'ailleurs je suis preneur d'idées pour les icones des boutons, là dessus je sèche, et c'est surement à l'origine de quelques incompréhensions.

Avec ce commentaire sur les boutons je me dis que peut-être en effet il y a incompréhension, parce qu'au final, {{ ou {% (voire {#) doivent pouvoir être posés aux mêmes endroits, i.e. on voudra aussi bien poser un {% au milieu d'une phrase,

bonjour {% if form_var_title == "Mme" %}madame{% else %}monsieur{% endif %}

que poser un {{ à la "racine"

<p>une nouvelle demande a été soumise, voici son contenu :</p>
{{form_details}}

Il y a bien une différence, sur la possibilité de mise en forme, i.e. on ne souhaite pas permettre :

bonjour <b>{% if form_var_title == "Mme" %}</b>madame{% else %}monsieur{% endif %}

mais aujourd'hui la différence posée entre {{ et {% dépasse ça, avec des critères de où ça se plasse dans le document.

Je ne tenterai pas d'avoir au niveau de godo un contenu grammaticalement correcte au niveau Template Django, je pense plus viable de viser uniquement une correction syntaxique, via des noeuds virtuels qui produisent du contenu {{ }} et {% %} en sortie.

J'ai l'impression que le but du ticket c'était de pouvoir taper des directives Django dans la vue HTML, ça devrait rester le seul but, tant pis si le template est finalement invalide ensuite. Le souci c'est d'imposer le passage par la vue source. Surtout il est important que tous les templates existant et syntaxiquement corrects soient représentables je pense.

Plus une remarque de forme mais vérifier que la grammaire HTML est respectée suite à l'interprétation du template est bonne même Django ne le permet pas, et ici ça demanderait de maintenir dans godo toutes les directives et leurs différents appairages (if/elif/endif, with/endwith, etc...for/ifempty/endfor) ou alors de limiter les possibilités (n'autoriser que if/endif, with/endwith et for/endfor et comme cela on a des vrais blocs avec un début, une fin et une imbrication clair). Et faire ce dernier choix empêcherait de récupérer les templates existant dans l'éditeur, certains ne seraient pas représentables.

Mes 50 cents :

l'aide contextuelle quand on garde le curseur sur le bouton "{%" "Supprimer le bloc HTML pour insérer une balise Django" ne me semble pas très explicite pour un utilisateur pas technique.
J'ai mis un moment à en comprendre l'utilité.

Notes suite échange avec Clément.

• Bug: ne pas autoriser les retours chariot au sein des tag django.
• La vue code lui semble à première vu indispensable (surtout par habitude avec CKEditor), mais après un temps d'essais plus long pas forcement.
• L'icon `{%` et son tooltips "Supprimer le bloc html pour insérer une balise Django" n'est pas très clair.
  • proposition de `<>x` pour "supprimer le tag HTML" mais ne réfère rien sur
  • `↤{⋅}`
• L'icon `+ {{` pourrait être rempacé par `+{⋅}` pour juste indiquer qu'on insère une balise djando, sans induire sur une variable ou un tag.
• Idée: ajouter une section "Editeur Godo" dans la documentation avec pourquoi pas un lien (?) depuis l'editeur qui pointe vers cette page de documentation.