Project

General

Profile

Development #52073

composition graphique grille fiche

Added by Frédéric Péters 6 months ago. Updated about 2 months ago.

Status:
Solution déployée
Priority:
Normal
Assignee:
Target version:
-
Start date:
16 Mar 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

(pour l'objectif général #50694, mais la maquette là peut être ignorée dans ses détails)

Mon idée pour ce ticket est de se concentrer sur la partie composition de la grille, en détachant ça des considérations détaillées de patch combo (i.e. l'intégration technique viendra derrière).

Ce que j'imagine c'est qu'on ait comme info le schéma des données, i.e. une liste de champs, ex:

{"fields": [{"id": "name", "label": "Nom", "type": "string"}, ...]}

et qu'on veut permettre en retour la production d'un json de description d'une composition en grille de champs tirés de la liste ci-dessus (pas nécessairement tous).

Je pense qu'au plus simple cette description devra suivre la piste CSS choisie, par exemple pour le choix CSS grid ça pourrait être :

{"cells": [{"field": "name", "column-start": 1, "column-end": 2, "row-start": 1, "row-end": 2}, ...]}

alors que si on choisissait CSS flex ça pourrait être :

{"rows": [{"field": "name", "grow": "2"}, ...], [...

et via notre système actuel à base de floats,

{"cells": [{"field": "name", "newline": true, "width": "1-2"}, ...]}

Files

0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch (16.4 KB) 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch Thomas Jund, 05 May 2021 03:37 PM
Screenshot_2021-05-11 Portail Agent.png (20.6 KB) Screenshot_2021-05-11 Portail Agent.png Frédéric Péters, 11 May 2021 09:08 AM
0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch (16.5 KB) 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch Thomas Jund, 11 May 2021 05:09 PM
0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch (16.2 KB) 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch Thomas Jund, 03 Jun 2021 03:20 PM
0001-card-cell-display-customize-content-layout-52073.patch (2.52 KB) 0001-card-cell-display-customize-content-layout-52073.patch Thomas Jund, 15 Jun 2021 07:20 PM
0001-card-infos-cell-form-add-i18n-52073.patch (5.62 KB) 0001-card-infos-cell-form-add-i18n-52073.patch Thomas Jund, 16 Jun 2021 04:18 PM
0002-card-cell-display-customize-content-layout-52073.patch (3.06 KB) 0002-card-cell-display-customize-content-layout-52073.patch Thomas Jund, 29 Jun 2021 05:12 PM
0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch (16.8 KB) 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch Thomas Jund, 29 Jun 2021 05:12 PM
one-field-in-grid-cell-form.png (20.9 KB) one-field-in-grid-cell-form.png Thomas Jund, 15 Jul 2021 02:39 PM
multi-fields-in-grid-cell-form.png (33.1 KB) multi-fields-in-grid-cell-form.png Thomas Jund, 15 Jul 2021 02:39 PM
Screenshot 2021-07-26 at 16-35-29 Services en ligne.png (19.2 KB) Screenshot 2021-07-26 at 16-35-29 Services en ligne.png Frédéric Péters, 26 Jul 2021 04:35 PM

Related issues

Related to Intégrations graphiques Publik - Development #52336: nouveau system de grille en flexboxSolution déployée24 Mar 2021

Actions
Related to Combo - Development #52498: cellule contenu d'une fiche, inclure dans l'HTML de l'édition des paramètres le schéma des donnéesSolution déployée30 Mar 2021

Actions
Related to Combo - Bug #53778: manager JS: scope global pour compute_max_heightSolution déployée05 May 2021

Actions
Related to Combo - Development #53780: manager JS: ajout des events cell:open & cell:closeSolution déployée05 May 2021

Actions
Related to Combo - Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden]Solution déployée25 May 2021

Actions
Related to Intégrations graphiques Publik - Bug #54911: suppresion balise sur selecteur .labelSolution déployée16 Jun 2021

Actions

Associated revisions

Revision 93ea996a (diff)
Added by Thomas Jund about 2 months ago

wcs: add support for custom content layout (#52073)

History

#1

Updated by Thomas Jund 6 months ago

En réfléchissant sur la conception de notre éditeur wysiwi(g/m) maison, je me demande dans quel cas ce ne serait pas judicieux de l'utiliser aussi pour cette cellule :
que notre éditeur propose un module grille, un peu comme ce qui se fait pour les tableaux en wysiwyg, et ensuite de pouvoir placer dans les grilles le contenu que l'on souhaite, pourquoi pas sous forme de variables django {{ name.label }} comme ça se fait déjà ailleurs sur la plateforme.
Il faudrait pouvoir lister quelque part dans la cellule les données disponibles.

Niveau grille, je serais pour en proposer une nouvelle en flexbox (parce que compatible IE11 côté Front) et pas d'interaction avec l'existant en Float.
CSS grid est pas mal, mais je pense trop peu compatible avec notre scope de browser supportés coté front.

#2

Updated by Pierre Cros 6 months ago

Vue en réunion du lundi, on peut partir sur le mockup de Fred https://dev.entrouvert.org/attachments/51547 (qui peut être ignoré dans ses détails écrivait Fred) pour arriver à un truc simple.

On pourra envisager un truc plus complexe (éventuellement à base d'éditeur wysiwig) plus tard.

#3

Updated by Thomas Jund 6 months ago

Je complète.
La proposition de faire 1 champ = une cellule de grille me semblait trop contraignant et peut-être pas adapté aux cas d'usages les plus fréquents, surtout avec les problématiques de responsive.
Pour Pierre, le problème peut être levé en travaillant les contenus complexes, les textes complémentaires ou les agrégations de champs à travers la création de nouveaux champs, comme des champs commentaires, au sein du modèle de fiche.
Donc Banco.
(Perso, je ne trouve pas terrible d'utiliser/complexifier le modèle de fiche pour de l'éditorial).

#4

Updated by Thomas Jund 6 months ago

#5

Updated by Frédéric Péters 6 months ago

Pour Pierre, le problème peut être levé en travaillant les contenus complexes, les textes complémentaires ou les agrégations de champs à travers la création de nouveaux champs, comme des champs commentaires, au sein du modèle de fiche.

Je ne pense pas, mon évolution prévue, c'était, dans le schéma, là où j'écrivais :

{"rows": [{"field": "name", "grow": "2"}, ...], [...

La possibilité d'avoir autre chose que "field": "name", genre,

{"rows": [{"title": "Bonjour", "grow": "2"}, ...], [...

Éléments pas liés aux données, totalement indépendants, gérés dans Combo.

#6

Updated by Thomas Jund 5 months ago

  • Status changed from Nouveau to En cours
#8

Updated by Frédéric Péters 5 months ago

  • Related to Development #52498: cellule contenu d'une fiche, inclure dans l'HTML de l'édition des paramètres le schéma des données added
#9

Updated by Thomas Jund 5 months ago

Travail en cours et premières réflexions :

Lien entre select "Modèle de Fiche" et "grille de personnalisation"

Une personnalisation est lié à un modèle de fiche. La cellule possède un select qui permet de sélectionner/modifier le modèle de fiche. Si changement du modèle de fiche alors qu'une personnalisation existe. Il n'y a plus de correspondance.
  • Lorsque l'utilisateur active l'option de personnalisation, faut-il verrouiller le modèle de fiche sélectionné ?
  • Lorsque l'utilisateur change de modèle de fiche, faut-il effacer toute personnalisation existante ?

Modification du modèle et personnalisation existante

Autre point de friction.
Je créé un Json de personnalisation à partir du schema provenant du modèle.

schéma du modèle :

{
  "name": "Lieu",
  "fields": [
    {
      "type": "string",
      "label": "Nom du lieu",
      "prefill": {
        "type": "none",
        "locked": false
      },
      "varname": "nom",
      "required": true,
      "anonymise": true
    },
    {

dans le schema ,Les fields non pas d'id non modifiable généré à la création du champ.

L'usager sélectionne le champ "Nom du lieu" pour le placer dans sa grille, il ajoute un objet au Json décrivant les cellules de la grille de personnalisation

{
  "class":"fx-grid--auto",
  "cells_order":[0,2,1],
  "cells":[
    {
      "label":"Nom du lieu",
      "class":"",
      "diplay":["key","value"],
      "id":0},…

Que se passe-t-il si un admin fonctionnel modifie le champ "Nom du Lieu" ? Il faudrait pouvoir répercuter ces modifs dans l'objet de la cellule. Mais je ne vois pas comment faire en l'état.

#10

Updated by Frédéric Péters 5 months ago

Lorsque l'utilisateur active l'option de personnalisation, faut-il verrouiller le modèle de fiche sélectionné ?

Je dirais que oui. (mais ça me va d'ignorer ça pour le moment; en fait j'imagine qu'on pourrait avoir une popup lors de l'ajout d'une cellule de type fiche, dans la popup choisir le modèle, et que ça reste ensuite figé).

dans le schema ,Les fields non pas d'id non modifiable généré à la création du champ.

ok ça manque il faut ajouter ça il n'y a rien d'autre sur quoi tu pourrais te baser.

#11

Updated by Frédéric Péters 5 months ago

dans le schema ,Les fields non pas d'id non modifiable généré à la création du champ.

ok ça manque il faut ajouter ça il n'y a rien d'autre sur quoi tu pourrais te baser.

En fait à rédiger un ticket en ce sens je me mets à hésiter, l'identifiant qui compte c'est vraiment celui qui est manuellement défini, c'est lui qu'on retrouvera dans l'API retournant les données.

Donc ça me semble normal d'en faire la référence, et si il est modifié en cours de route, c'est la même punition ici qu'ailleurs : la personne qui fait la modification doit s'assurer partout que ça continue à être ok (comme aujourd'hui il faut par exemple vérifier les conditions qui l'utiliseraient).

#12

Updated by Thomas Jund 5 months ago

l'identifiant qui compte c'est vraiment celui qui est manuellement défini,

Ok donc seuls les champs avec un identifiant "varname" seront disponibles.
La relation se fait via cet identifiant. Si il change, ça casse (à voir si ensuite on met en place une vérif et une alerte).

#13

Updated by Frédéric Péters 5 months ago

Ok donc seuls les champs avec un identifiant "varname" seront disponibles.

Oui les données des autres ne sont de toute façon pas reprises dans l'API retournant les données d'une fiche.

#14

Updated by Thomas Jund 5 months ago

Première version alpha ?

Besoin de testeurs de l'IU pour des premiers retours

Pour tester :

  • combo: `git checkout wip/52073-card-cell`
  • publik-base-theme: `git checkout wip/52336-flex-grid`

Quelques remarques

  • J'ai bien galéré avec la function existante compute_max_height() qui gère le calcul de la taille des cell ouvertes; Pour le moment je l'ai déplacée pour la rendre globale et pouvoir l'utiliser dans mon script
  • J'ai également ajouté les events `cell:open` et `cell:close`

Ces 2 remarques seront des tickets séparés

  • J'ai encore des ajustements CSS à faire (pas de panique).
  • Pas mal de rangement dans mes methodes.
  • J'utilise jQueryUI modal et sortable.
  • Le code est dans combo.manager.js, mais je pense qu'il serait préférable de l'isoler.
  • Pour visualiser l'objet créé, à chaque changement, le json s'affiche dans la console du navigateur.

Il y aurait plein de trucs à dire, à vos questions…

#15

Updated by Thomas Jund 5 months ago

branch rebase et patch

#16

Updated by Thomas Jund 5 months ago

  • Related to Bug #53778: manager JS: scope global pour compute_max_height added
#17

Updated by Thomas Jund 5 months ago

  • Related to Development #53780: manager JS: ajout des events cell:open & cell:close added
#18

Updated by Frédéric Péters 4 months ago

J'imagine #52336 nécessaire (grid/flexbox) mais le ticket est rangé dans "Publik", me semble pour publik-base-theme, mais ici je suis dans la composition graphique dans le backoffice et donc ça devrait aussi être gadjo, tu pourrais produire des patchs/branches ? (dans "pour tester" tu écris publik-base-theme: `git checkout wip/52073-card-cell` mais cette branche n'existe pas là).

Une fois tapé n'importe comment dans mon gadjo local, ça me semble fonctionner mais il manque peut-être encore des styles ici (en pièce jointe ce que ça me donne); je pense particulièrement à la position des icônes de modification/suppression et au bouton "ajouter" qui se met dans la grille et change de taille selon l'ajout de champs.

Sur le fonctionnment, j'ai bien lu que c'était encore marqué TODO mais l'idée du "Personnaliser l'affichage", c'est de plier/déplier la section d'édition ?

Sur les tests, comme il n'y a pas d'enregistrement, on est d'accord qu'on ne peut rien voir en front ?

#19

Updated by Thomas Jund 4 months ago

Frédéric Péters a écrit :

J'imagine #52336 nécessaire (grid/flexbox) … tu pourrais produire des patchs/branches ? (dans "pour tester" tu écris publik-base-theme: `git checkout wip/52073-card-cell` mais cette branche n'existe pas là).

Oui ce patch/branch est lié et necessaire. La branch existe (mauvais copier-coller) c'est wip/52336-flex-grid (je met à jour le message précedent)

mais le ticket est rangé dans "Publik", me semble pour publik-base-theme, mais ici je suis dans la composition graphique dans le backoffice et donc ça devrait aussi être gadjo.

Comme ça concerne à la fois publik-base-theme et gadjo, je l'ai posé dans "Publik". Mais je peux le déplacer si ça te semble illogique

en pièce jointe ce que ça me donne;

Ça correspond à l'état actuel

je pense particulièrement à la position des icônes de modification/suppression

tu les verrais plutôt sur la gauche ?

et au bouton "ajouter" qui se met dans la grille et change de taille selon l'ajout de champs.

il prend la place de la cellule à ajouter. Dans ta capture le bouton prend toute la largeur parce qu'une nouvelle cellule en "auto" prendra cette taille.

Sur le fonctionnment, j'ai bien lu que c'était encore marqué TODO mais l'idée du "Personnaliser l'affichage", c'est de plier/déplier la section d'édition ?

Oui, mais pas que, je pensais aussi lancer le JS en fonction de l'état de ce bouton.
Je ne sais pas si ce checkbox doit être dans la définition du formulaire en python ou ajouter dans le template html. Mais je te laisserais modifier.

Sur les tests, comme il n'y a pas d'enregistrement, on est d'accord qu'on ne peut rien voir en front ?

Exact

J'aimerais bien aussi ton retour/avis sur

  • Les options de mise en forme des champs de la fiche. Pour le moment j'a mis "label + Valeur" et "Valeur uniquement". Sur ton mockup tu proposais "Titre" aussi : ton idée était de pouvroi afficher la valeur sous forme de titre ?
  • La structure du JSON de la personnalisation.
  • Le fait que si une personnalisation existe, la cellule retourne le JSON de personnalisation et JS construit l'UI.
  • Le fait d'avoir posé les templates nécessaires à l'UI de customisation dans le fichier html au sein de balises <script type="text/template" />
#20

Updated by Frédéric Péters 4 months ago

Comme ça concerne à la fois publik-base-theme et gadjo, je l'ai posé dans "Publik". Mais je peux le déplacer si ça te semble illogique

Oui plutôt avoir des tickets dans les projets techniques réels, perso je ne regarde jamais s'il y a des patchs en attente dans le projet Publik.

Je ne sais pas si ce checkbox doit être dans la définition du formulaire en python ou ajouter dans le template html. Mais je te laisserais modifier.

Je dirais que ça doit être dans la définition du formulaire, pour permettre de désactiver/réactiver, sans perdre.

je pense particulièrement à la position des icônes de modification/suppression

tu les verrais plutôt sur la gauche ?

Peut-être un bouton explicitement sous forme de bouton avec du texte genre "paramétrage" pour le bouton "modifier" actuel et le bouton de suppression aligné sur la droite (voire en haut à droite même si je crains la confusion avec une "fermeture" qui ne serait pas destructive.

il prend la place de la cellule à ajouter. Dans ta capture le bouton prend toute la largeur parce qu'une nouvelle cellule en "auto" prendra cette taille.

Ok ça m'a semblé bizarre; je pense que j'aurais été plus à l'aise avec un bouton toujours placé pareil dessous.

La structure du JSON de la personnalisation.

Elle part un peu bizarre quand on supprime des éléments :

{"grid_class": "fx-grid--auto",
 "grid_layout_label": "auto",
 "cells_order": [3, 4, 5],
 "cells": [
   null,
   null,
   null,
  {"varname":"nom","cell_size":"","display":["key","value"],"cell_size_label":"auto","id":3},
  {"varname":"nom","cell_size":"","display":["key","value"],"cell_size_label":"auto","id":4},
  {"varname":"nom","cell_size":"","display":["key","value"],"cell_size_label":"auto","id":5},
  null,
  null
 ]
}

je pense que ce qui est supprimé doit être supprimé (plutôt qu'avoir null), et je serais plutôt pour avoir la liste maintenue dans l'ordre attendu plutôt qu'une deuxième liste (cells_order) pour en donner l'ordre.

Le fait que si une personnalisation existe, la cellule retourne le JSON de personnalisation et JS construit l'UI.

#21

Updated by Frédéric Péters 4 months ago

(validé trop vite je continue)

Le fait que si une personnalisation existe, la cellule retourne le JSON de personnalisation et JS construit l'UI.

Je ne comprends pas la question.

Les options de mise en forme des champs de la fiche. Pour le moment j'a mis "label + Valeur" et "Valeur uniquement". Sur ton mockup tu proposais "Titre" aussi : ton idée était de pouvroi afficher la valeur sous forme de titre ?

Oui, par exemple pour une fiche parking on aurait "nom du parking sous forme de titre" puis "adresse (valeur)" puis "nombre de places (libellé et valeur)"

Le fait d'avoir posé les templates nécessaires à l'UI de customisation dans le fichier html au sein de balises <script type="text/template" />

Je me suis dit que c'était pratique pour y intégrer les traductions.

#22

Updated by Thomas Jund 4 months ago

Modifications :

Peut-être un bouton explicitement sous forme de bouton avec du texte genre "paramétrage" pour le bouton "modifier" actuel et le bouton de suppression aligné sur la droite (voire en haut à droite même si je crains la confusion avec une "fermeture" qui ne serait pas destructive.

Utilisation des labels "Modifier" et "supprimer", "supprimer" ferré à gauche.

Ok ça m'a semblé bizarre; je pense que j'aurais été plus à l'aise avec un bouton toujours placé pareil dessous.

Done

je pense que ce qui est supprimé doit être supprimé (plutôt qu'avoir null), et je serais plutôt pour avoir la liste maintenue dans l'ordre attendu plutôt qu'une deuxième liste (cells_order) pour en donner l'ordre.

Done

Oui, par exemple pour une fiche parking on aurait "nom du parking sous forme de titre"

Ok, j'ai ajouté l'entrée "titre". Il faut peut-être revoir les labels d'affichage.

====

Le fait que si une personnalisation existe, la cellule retourne le JSON de personnalisation et JS construit l'UI.

Je ne comprends pas la question.

Voir dans card_infos-cell-forms.html le commentaire {# Si une personnalisation existe déjà, simplement retourner le Json dans la cellule #}

#23

Updated by Frédéric Péters 4 months ago

Le fait que si une personnalisation existe, la cellule retourne le JSON de personnalisation et JS construit l'UI.

Je ne comprends pas la question.

Voir dans card_infos-cell-forms.html le commentaire {# Si une personnalisation existe déjà, simplement retourner le Json dans la cellule #}

J'ai encore du mal, je tente : la question serait « une fois que les données seront enregistrées, elles seront présentes dans une variable qui pourra être mise dans le gabarit, histoire de ne pas repartir de zéro à chaque fois ? » ce qui n'aurait pas de sens, finalement non vraiment je ne ne vois pas quelle est la question.

#24

Updated by Thomas Jund 4 months ago

Question envoie des données au serveur.

Est-ce qu'on ajoute un textarea hidden au formulaire pour y stocker le dictionnaire de personnalisation ? Cela permetterait de conserver le fonctionnement du bouton enregistrer.
Ou on envoie les datas au serveur par ajax ?

#25

Updated by Frédéric Péters 4 months ago

Est-ce qu'on ajoute un textarea hidden

Ce qui va se passer c'est qu'il y aura un champ en plus dans le modèle de données et dans le rendu du formulaire ça fera selon toute vraisemblance un <input type=hidden, et donc oui toute la mécanique d'enregistrement etc. actuelle est conservée.

#26

Updated by Thomas Jund 4 months ago

  • Related to Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden] added
#27

Updated by Thomas Jund 4 months ago

  • Status changed from Solution proposée to En cours

J'ai pluggé le JS sur le nouveau formulaire. Branch à jour.

Pour tester :

combo: `git checkout wip/52073-card-cell`
gadjo: `git checkout wip/54488-flexbox-grid`

Il me reste 2 petits soucis à régler :
https://dev.entrouvert.org/issues/54259#note-4
https://dev.entrouvert.org/issues/54259#note-5

#28

Updated by Thomas Jund 4 months ago

  • Related to deleted (Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden])
#29

Updated by Thomas Jund 4 months ago

  • Blocked by Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden] added
#31

Updated by Thomas Jund 4 months ago

Patch dispo pour relecture

#32

Updated by Thomas Jund 4 months ago

  • Blocked by deleted (Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden])
#33

Updated by Thomas Jund 4 months ago

  • Related to Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden] added
#34

Updated by Frédéric Péters 3 months ago

+{# Grille de personalisation #}
...
+    <a role="button" class="wcs-cards-cell--grid-layout-btn">
+      Modifier

Il faudrait écrire en anglais et utiliser la mécanique de traduction; il faut ajouter en haut de fichier (après l'extends) {% load i18n %} puis pour le texte qui doit apparaitre traduit passer par le tag trans, ex:

{% trans "Edit" %}

Il y a une infra également pour avoir des traductions côté js mais c'est aussi tout à fait possible de poser simplement les chaines attendues depuis le gabarit, puis les exploiter dans le .js, par ex:

dans l'html,
<script>
window.combo_i18n = Object();  //
window.combo_i18n.cancel = "{% trans 'Cancel' %}";
</script>

dans le js,
+      buttons: [
+        {
+          text: window.combo_i18n.cancel,
#35

Updated by Thomas Jund 3 months ago

Il faudrait écrire en anglais et utiliser la mécanique de traduction

OK, je vais essayer


Voici le patch qui met permet d'afficher le résultat coté Front. Avis bienvenue car je trouve qu'il y a beaucoup d'imbrications et de redondance

Notemment la redondance de

                  {% if field.type == "date" %}
                    {{ value|date }}
                  {% elif field.type == "bool" and value is not None %}
                    {{ value|yesno }}
                  {% else %}
                    {{ value|default:"" }}
                  {% endif %}

Laureline me conseille de faire un include.  Ça te parait bien Fred ?

Je vais rebaser tout ça (suite à une modif de Laureline côté form) et pousser

#36

Updated by Thomas Jund 3 months ago

  • Related to Bug #54911: suppresion balise sur selecteur .label added
#38

Updated by Thomas Jund 3 months ago

Petit récapitulatif pour faire avancer ce projet. Parce que beaucoup de tickets/patchs en découle

Tickets en relation à relire :

  • System de grille flexbox
    • Ajout de la grille à Publik-base-theme #52336
    • Le même system ajouté à Gadjo #54488
    • Rendre compatible avec la grille float : #54904
  • Modifications du formulaire de la cellule côté combo #54259
#39

Updated by Frédéric Péters 3 months ago

Je pense que la composition personnalisée devrait également concerner le titre de la cellule et je pense que ça doit être intégré dès maintenant pour qu'il n'y ait pas de transition compliquée à gérer.

Côté code il me semble opportun d'extraire (vers mettons templates/combo/wcs/card-field-value.html) dès maintenant la partie d'affichage d'une valeur de champ,

+                  {% if field.type == "date" %}
+                    {{ value|date }}
+                  {% elif field.type == "bool" and value is not None %}
+                    {{ value|yesno }}
+                  {% else %}
+                    {{ value|default:"" }}
+                  {% endif %}

plutôt que la répéter.

J'aimerais voir une branche avec les éléments de "add i18n" intégrés dans le commit avec le code.

Le commie "add i18n", je sais que c'est un commentaire mais 1/ typo, 2/ quand même, devait également avoir ses commentaires en anglais.

@@ -8,15 +9,15 @@
 {# Grille de personalisation #}
#40

Updated by Thomas Jund 3 months ago

Je pense que la composition personnalisée devrait également concerner le titre de la cellule

Tu penses à #54549 ?
J'ai déjà rebasé wip/52073-card-cell dessus.

J'aimerais voir une branche avec les éléments de "add i18n" intégrés dans le commit avec le code.

Le commit est déjà intégré à la branch, je squash les 2 commits

templates/combo/wcs/card-field-value.html

Ok, je préfère aussi.

#41

Updated by Frédéric Péters 3 months ago

Tu penses à #54549 ?

Ce ticket concerne la cellule "Fiches", pas la cellule "Fiche".

Mais peut-être que oui on pourrait imaginer que la personnalisation du titre ne passe pas par la composition graphique mais par un champ comme dans #54549.

J'ai déjà rebasé wip/52073-card-cell dessus.

Je me base sur https://git.entrouvert.org/combo.git/log?h=wip%2F52073-card-cell et ce n'est pas le cas.

#42

Updated by Thomas Jund 3 months ago

Patch 0001 pour 'card-infos-cell-form' avec i18n et commentaires en 'en'.
Patch 0002 pour 'card.html' avec 'card-field-value.html'

Mais peut-être que oui on pourrait imaginer que la personnalisation du titre ne passe pas par la composition graphique mais par un champ comme dans #54549.

Cela me paraitrait plus logique de conserver ce même comportement (Il y a peu d'intérêt de déplacer la titre de la cellule).

Branch rebasé sur wip/54259-custom-schema

#43

Updated by Frédéric Péters 3 months ago

Échec du test,

>       assert '<span class="label">Field A</span>\n    \n    <span class="value">a</span>' in result

je serais à ne pas faire des tests dépendant si précisément d'espaces et retours à la ligne. (même sans savoir si ça vient de là).

#44

Updated by Serghei Mihai 3 months ago

  • Status changed from Solution proposée to En cours

Je pense qu'on pourrait partir sur pyquery: https://pythonhosted.org/pyquery/ (utilisé dans les tests d'authentic)

Il n'y aura plus à gérer les sauts des lignes et espaces entre les balises.

from pyquery import PyQuery as pq
...

    d = pq(result)
    assert d('h2').text == 'Card Model 1 - aa'

    assert d('span.label')[0].text.strip() == 'Field A'
    assert d('span.value')[0].text.strip() == 'a'

    assert d('span.label')[1].text.strip() == 'Field B'
    assert d('span.value')[1].text.strip() == 'yes'

    assert d('span.label')[2].text.strip() == 'Field C'
    assert d('span.value')[2].text.strip() == 'Sept. 28, 2020'

    assert d('span.label')[3].text.strip() == 'Related'
    assert d('span.value')[3].text.strip() == 'Foo Bar'
#45

Updated by Frédéric Péters 3 months ago

J'ai retiré le dernier commit (sujet: "less readable code because fucking test") et ajouté un nouveau, qui :

  • utilise {% spaceless %} pour réduire le nombre d'espaces/retours à la ligne dans la sortie, ce qui produit quand même quelque chose de plus facilement directement lisible,
<p><span class="label">Field A</span><span class="value">a
</span></p><p><span class="label">Field B</span><span class="value">yes
</span></p><p><span class="label">Field C</span><span class="value">Sept. 28, 2020
</span></p><p><span class="label">Related</span><span class="value">Foo Bar
</span></p>
  • il reste ces retours à la ligne c'est https://code.djangoproject.com/ticket/9198 et le seul contournement aujourd'hui serait de ne pas inclure el retour à la ligne final dans le fichier inclus mais ça ne tiendra pas aux éditions successives, donc j'ai laissé.
  • bascule des tests pour utiliser pyquery pour ne pas dépendre d'un nombre précis d'espaces et retours à la ligne, basiquement :
-    assert '<span class="label">Field A</span>\n    \n    <span class="value">a</span>' in result
+    assert PyQuery(result).find('span.label:contains("Field A") + span').text() == 'a'
#47

Updated by Frédéric Péters 2 months ago

(Ce shéma avait été présenté à Fred par Jabber et retoqué initialement).

Ma question en fait ne porte pas vraiment sur le format de stockage, là-dessus on a des procédures de migration existantes.

Ma question porte sur la manière même de définir la grille, parce qu'on peut assurer une conversion quand on ne fait qu'ajouter des possibilités, mais quand on en perd, ça foire; exemple sur la situation des grilles : le "newline" qui existe pour faire des lignes incomplètes en grille float, qu'on n'arrive pas à convertir ici en grille flex.

Et donc, assurer qu'il y ait un plan d'évolution, dès maintenant, qui permettra

-------      |  info d'un autre champ 1
l'info       |  -----------------------   
d'un         |  info d'un autre champ 2
champ 0      |  ------------------------
-------      |  info d'un autre champ 3

évolution qui soit une évolution, et pas une réécriture différente avec des manques différents.

De manière pratique, les deux possibilités sont "imbriquer des flex" ou "remplacer par un système basé sur css grid" (avec limitations IE connues), et donc la question sur "imbriquer des flex", c'est aussi réfléchir en terme d'UI, voit-on un moyen simple, ou au moins clair, pour gérer ça ?

#48

Updated by Thomas Jund 2 months ago

De manière pratique, les deux possibilités sont "imbriquer des flex" ou "remplacer par un système basé sur css grid" (avec limitations IE connues), et donc la question sur "imbriquer des flex", c'est aussi réfléchir en terme d'UI, voit-on un moyen simple, ou au moins clair, pour gérer ça ?

Mes tests d'hier sont non concluants sur ces 2 solutions. Les 2 impliques un UI trop complexe.
CSS grid necessite de définir la grille (nombre et row et cols et leurs taille) pour ensuite venir positionner les cellules dans les bonnes cases. En cas de changement de la définir de la grille, tout va péter.
Flexbox imbriqué idem. Pas trouvé de solution viable côté UI.

Pour moi les solutions les plus simple sont dans la possibilité d'être plus souple au niveau du contenu dans une cellule de grille : pouvoir sortir de "1 field == 1 grid cell" avec les solutions que j'avance au dessus.

#49

Updated by Frédéric Péters 2 months ago

Je ne comprends pas ta réponse :

Pour moi les solutions les plus simple sont dans la possibilité d'être plus souple au niveau du contenu dans une cellule de grille : pouvoir sortir de "1 field == 1 grid cell" avec les solutions que j'avance au dessus.

Correspond pour moi à "flex imbriqué".

#50

Updated by Frédéric Péters 2 months ago

De manière pratique, en ignorant ce que j'écris, à quelles évolutions d'UI correspondraient ton point "Avoir la possibilité de déclarer plusieurs champs de fiche au sein d'une cellule".

#51

Updated by Thomas Jund 2 months ago

Ça se ferait en améliorant le formulaire d'ajout/modification d'une cellule de grille en permettant de choisir plusieurs champs de fiche.

#52

Updated by Frédéric Péters 2 months ago

Ok; et je ne capte donc pas "Les 2 impliquent un UI trop complexe" parce que pour moi on est pile sur le cas "flexbox imbriqués". Soit ça n'a pas d'importance que je ne comprenne pas la différence que tu fais, et ok, soit tu crains que cette incompréhension pose un doute général sur l'affaire, et on essaie de la lever.

#53

Updated by Thomas Jund 2 months ago

Par flexbox imbriqués, je comprends "grilles flexbox imbriquées", donc la possibilité de configurer une grille au sein d'une cellule de grille, avec un markup de type

<div class="grid">
    <div class="grid-cell">
        <div class="grid">
            <div class="grid-cell">fields 1</div>
            <div class="grid-cell">fields 2</div>
            <div class="grid-cell">fields 3</div>
        </div>
    </div>
</div>

ALors que ma proposition se contente juste de pouvoir empiler dans le flux d'une cellule de grille plusieurs champs

<div class="grid">
    <div class="grid-cell">
        fields 1
        fields 2
        fields 3
    </div>
</div>

Pour moi, il n'y a pas de flexbox imbriqués.

#54

Updated by Frédéric Péters 2 months ago

Ok je capte la différence, donc pas possible de

-------      |  info d'un autre champ 1
l'info       |  qui se fait sur   
d'un         |  deux-tiers de la hauteur
champ 0      |  ------------------------
-------      |  info d'un autre champ 2

mais de la proposition,

            "children": [
              {
                "display": ["title"],
                "varname": "field_1" 
              },
              {
                "display": ["value"],
                "varname": "field_2" 
              },
              …
            ]

je ne faisais pas le lien, ça doit être la liste sur les clés display qui m'a perturbé.

Ce qui me fait prendre en compte celle-ci maintenant; je la trouve bizarre. (je mets de ce côté cette remarque, j'y reviens à la fin).

Pour reprendre et avoir dans un commentaire la situation présente, on a :

"cells": [
   {
     "cell_size": "",
     "cell_size_label": "Automatic",
     "display": ["key", "value"],
     "varname": "nom" 
   }
   ...

et la proposition est

"cells": [
   {
     "cell_size": "",
     "cell_size_label": "Automatic",
     "children": [
        {
          "display": ["key", "value"],
          "varname": "nom",
        }
     ]
   }
   ...

i.e. on avait un élément unitaire "cell", qui correspondait à un emplacement grille + un contenu, et on passerait à un élément qui correspondrait à emplacement grille + à l'intérieur un élément secondaire "contenu".

Et à remonter à mon "flex imbriqué", ça aurait été :

"cells": [ {
"cell_size": "",
"cell_size_label": "Automatic",
"children": [ {
"cell_size": "",
"cell_size_label": "Automatic",
"display": ["key", "value"],
"varname": "nom"
}
}
...

i.e. pour reprendre ton UI, l'ajout d'un paramètre "cell_size".

Mais pourtant, « Les 2 impliquent un UI trop complexe » alors que j'y imagine juste un attribut supplémentaire. (?)

~~

Pour revenir à la clé "display", pour moi elle correspond au mode d'affichage (titre, libellé, valeur, libellé et valeur) et il s'agit du choix dans une série de modes d'affichage, i.e. je m'attendrais à avoir des valeurs title, label, value, label-and-value, plutôt que ['title'], ['label'], ['value'], ['label', 'value'], qui sous-entend des possibilités pas présentes.

#55

Updated by Thomas Jund 2 months ago

info d'un autre champ 1 qui se fait sur deux-tiers de la hauteur

On a un cas d'usage pour ce besoin ?
En responsive, on a tendance très majoritairement à gérer la largeur de l'écran et donc de laisser le height en auto, parce que retour à la ligne de texte etc.
De plus, maitriser un minimum le height du genre "2 tiers de la hauteur du bloc parent, qui lui même est calé en "stetch" par rapport à son voisin" demande dans ton exemple de basculer en `flex-direction: column`.

i.e. pour reprendre ton UI, l'ajout d'un paramètre "cell_size".

(cell_size correspond donc a la largeur de l'élément).
On aurait donc une Ui de premier niveau qui présente une disposition en grille qui évolue en fonction des paramètres de la grille et de ces cellules, pour la grille de premier niveau. Mais pas pour les grilles imbriquées où l'UI ne reflétera pas les choix ?
Ajouter juste un select cell_size dans le formulaire de la cellule ne suffirait pas, il faudra exposer ces choix de mise en forme dans la vue principale.

et j'aurais besoin d'un cas d'usage là aussi. Pour le cas d'usage qui nous sert de référence à cette discussion, il est inutile de faire des grilles imbriquées.

Pour revenir à la clé "display", pour moi elle correspond au mode d'affichage

Pas seulement, c'est un truc batard dont je ne suis pas satisfait, qui mélange le type de contenu (label et/ou valeur) et sa mise en forme (titre, mais à venir image, bouton, etc.). Pourquoi la mise en forme "Titre" serait réservé à la valeur et pas utilisable avec le label ?
J'en ai fait un array pour simplifier le templating côté JS.

#56

Updated by Frédéric Péters 2 months ago

(cell_size correspond donc a la largeur de l'élément).

La hauteur quand on est sur une disposition verticale.

On aurait donc une Ui de premier niveau qui présente une disposition en grille qui évolue en fonction des paramètres de la grille et de ces cellules, pour la grille de premier niveau. Mais pas pour les grilles imbriquées où l'UI ne reflétera pas les choix ?

Je ne vois pas ce qui empêche l'interface de refléter.

et j'aurais besoin d'un cas d'usage là aussi. Pour le cas d'usage qui nous sert de référence à cette discussion, il est inutile de faire des grilles imbriquées.

L'idée générale est qu'en terme d'évolution on puisse avoir davantage que des champs des fiches, par exemple la possibilité d'ajouter un lien.

-------      |  titre autre champ
l'image      |  texte encore autre champ
d'un         |  plusieurs lignes
champ 0      |  ------------------------
-------      |  zone lien "voir plus" 

Et cette zone lien "voir plus", on la voudrait "flex-end", pour être alignée sur le bas.

~~

Mais ok mettons ça de côté si on ne considère pas l'évolution impossible, elle viendra en son temps.

~~

Pour revenir à la clé "display", pour moi elle correspond au mode d'affichage

Pas seulement (...)

Oui, ce que je voulais écrire c'est "pour moi elle devrait correspondre au mode d'affichage" et le fait que ça ne soit pas le cas fait un truc bizarre, que je trouverais à revoir, surtout si tu n'es toi-même pas fan.

#57

Updated by Thomas Jund 2 months ago

Et cette zone lien "voir plus", on la voudrait "flex-end", pour être alignée sur le bas.

Ok, par grilles imbriqués tu pensais à la possibilité d'une répartition vertical des éléments "uniquement" . Donc pas focement de répliquer toutes les mêmes options de la grille parent vers la grille enfant.
Au contraire, plutôt un mode flexbox "column" au sein des cellules.
Certain que le terme "grille imbriquée" fait appel à un imaginaire chez moi bien différent du tien.

#58

Updated by Frédéric Péters about 2 months ago

J'ai poussé une branche actualisée (par facilité locale basée sur #55792).

Dedans :

#59

Updated by Frédéric Péters about 2 months ago

+ https://git.entrouvert.org/combo.git/commit/?h=wip/52073-card-cell&id=9ebf94dd0cb3dd92e59a644d8910102c7e1bd6d9 pour utiliser le gettext js de django plutôt que le bricolage indépendant.

#60

Updated by Frédéric Péters about 2 months ago

  • Status changed from En cours to Solution validée

Il y a une branche avec tout ça squashé + rebasé suite aux nouvelles migrations. (il y a un commit partiel de traduction dedans, pour vérifier que la partie djangojs était ok, je compléterai).

(à relire je trouve que ça manque d'un test sur le rendu front d'une cellule avec layout custom mais je suis pour pousser ainsi quand même).

(et sauf objection d'ici fin de journée je vais pousser)

#61

Updated by Frédéric Péters about 2 months ago

Pour référence par rapport aux ~captures tapées dans le ticket aujourd'hui ça ressemble à celle-ci.

#62

Updated by Frédéric Péters about 2 months ago

  • Status changed from Solution validée to Résolu (à déployer)
commit 93ea996af9d7dec914151a6039d53729973a6006
Author: Thomas JUND <tjund@entrouvert.com>
Date:   Wed May 5 14:52:49 2021 +0200

    wcs: add support for custom content layout (#52073)
#63

Updated by Frédéric Péters about 2 months ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF