Projet

Général

Profil

Development #52073

composition graphique grille fiche

Ajouté par Frédéric Péters il y a environ 3 ans. Mis à jour il y a plus de 2 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
16 mars 2021
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

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"}, ...]}

Fichiers

0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch (16,4 ko) 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch Thomas Jund, 05 mai 2021 15:37
Screenshot_2021-05-11 Portail Agent.png (20,6 ko) Screenshot_2021-05-11 Portail Agent.png Frédéric Péters, 11 mai 2021 09:08
0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch (16,5 ko) 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch Thomas Jund, 11 mai 2021 17:09
0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch (16,2 ko) 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch Thomas Jund, 03 juin 2021 15:20
0001-card-cell-display-customize-content-layout-52073.patch (2,52 ko) 0001-card-cell-display-customize-content-layout-52073.patch Thomas Jund, 15 juin 2021 19:20
0001-card-infos-cell-form-add-i18n-52073.patch (5,62 ko) 0001-card-infos-cell-form-add-i18n-52073.patch Thomas Jund, 16 juin 2021 16:18
0002-card-cell-display-customize-content-layout-52073.patch (3,06 ko) 0002-card-cell-display-customize-content-layout-52073.patch Thomas Jund, 29 juin 2021 17:12
0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch (16,8 ko) 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch Thomas Jund, 29 juin 2021 17:12
one-field-in-grid-cell-form.png (20,9 ko) one-field-in-grid-cell-form.png Thomas Jund, 15 juillet 2021 14:39
multi-fields-in-grid-cell-form.png (33,1 ko) multi-fields-in-grid-cell-form.png Thomas Jund, 15 juillet 2021 14:39
Screenshot 2021-07-26 at 16-35-29 Services en ligne.png (19,2 ko) Screenshot 2021-07-26 at 16-35-29 Services en ligne.png Frédéric Péters, 26 juillet 2021 16:35

Demandes liées

Lié à Intégrations graphiques Publik - Development #52336: nouveau system de grille en flexboxFermé24 mars 2021

Actions
Lié à Combo - Development #52498: cellule contenu d'une fiche, inclure dans l'HTML de l'édition des paramètres le schéma des donnéesFermé30 mars 2021

Actions
Lié à Combo - Bug #53778: manager JS: scope global pour compute_max_heightFermé05 mai 2021

Actions
Lié à Combo - Development #53780: manager JS: ajout des events cell:open & cell:closeFermé05 mai 2021

Actions
Lié à Combo - Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden]Fermé25 mai 2021

Actions
Lié à Intégrations graphiques Publik - Bug #54911: suppresion balise sur selecteur .labelFermé16 juin 2021

Actions

Révisions associées

Révision 93ea996a (diff)
Ajouté par Thomas Jund il y a plus de 2 ans

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

Historique

#1

Mis à jour par Thomas Jund il y a environ 3 ans

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

Mis à jour par Pierre Cros il y a environ 3 ans

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

Mis à jour par Thomas Jund il y a environ 3 ans

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

Mis à jour par Thomas Jund il y a environ 3 ans

#5

Mis à jour par Frédéric Péters il y a presque 3 ans

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

Mis à jour par Thomas Jund il y a presque 3 ans

  • Statut changé de Nouveau à En cours
#8

Mis à jour par Frédéric Péters il y a presque 3 ans

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

Mis à jour par Thomas Jund il y a presque 3 ans

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

Mis à jour par Frédéric Péters il y a presque 3 ans

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

Mis à jour par Frédéric Péters il y a presque 3 ans

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

Mis à jour par Thomas Jund il y a presque 3 ans

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

Mis à jour par Frédéric Péters il y a presque 3 ans

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

Mis à jour par Thomas Jund il y a presque 3 ans

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

Mis à jour par Thomas Jund il y a presque 3 ans

branch rebase et patch

#16

Mis à jour par Thomas Jund il y a presque 3 ans

  • Lié à Bug #53778: manager JS: scope global pour compute_max_height ajouté
#17

Mis à jour par Thomas Jund il y a presque 3 ans

#18

Mis à jour par Frédéric Péters il y a presque 3 ans

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

Mis à jour par Thomas Jund il y a presque 3 ans

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

Mis à jour par Frédéric Péters il y a presque 3 ans

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

Mis à jour par Frédéric Péters il y a presque 3 ans

(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

Mis à jour par Thomas Jund il y a presque 3 ans

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

Mis à jour par Frédéric Péters il y a presque 3 ans

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

Mis à jour par Thomas Jund il y a presque 3 ans

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

Mis à jour par Frédéric Péters il y a presque 3 ans

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

Mis à jour par Thomas Jund il y a presque 3 ans

  • Lié à Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden] ajouté
#27

Mis à jour par Thomas Jund il y a presque 3 ans

  • Statut changé de Solution proposée à 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

Mis à jour par Thomas Jund il y a presque 3 ans

  • Lié à Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden] supprimé
#29

Mis à jour par Thomas Jund il y a presque 3 ans

  • Bloqué par Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden] ajouté
#31

Mis à jour par Thomas Jund il y a presque 3 ans

Patch dispo pour relecture

#32

Mis à jour par Thomas Jund il y a presque 3 ans

  • Bloqué par Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden] supprimé
#33

Mis à jour par Thomas Jund il y a presque 3 ans

  • Lié à Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden] ajouté
#34

Mis à jour par Frédéric Péters il y a presque 3 ans

+{# 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

Mis à jour par Thomas Jund il y a presque 3 ans

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

Mis à jour par Thomas Jund il y a presque 3 ans

  • Lié à Bug #54911: suppresion balise sur selecteur .label ajouté
#37

Mis à jour par Thomas Jund il y a presque 3 ans

patch i18n.

Branch rebasé et à jour.

#38

Mis à jour par Thomas Jund il y a presque 3 ans

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

Mis à jour par Frédéric Péters il y a plus de 2 ans

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

Mis à jour par Thomas Jund il y a plus de 2 ans

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

Mis à jour par Frédéric Péters il y a plus de 2 ans

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

Mis à jour par Thomas Jund il y a plus de 2 ans

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

Mis à jour par Frédéric Péters il y a plus de 2 ans

É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

Mis à jour par Serghei Mihai il y a plus de 2 ans

  • Statut changé de Solution proposée à 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

Mis à jour par Frédéric Péters il y a plus de 2 ans

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

Mis à jour par Frédéric Péters il y a plus de 2 ans

(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

Mis à jour par Thomas Jund il y a plus de 2 ans

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

Mis à jour par Frédéric Péters il y a plus de 2 ans

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

Mis à jour par Frédéric Péters il y a plus de 2 ans

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

Mis à jour par Thomas Jund il y a plus de 2 ans

Ç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

Mis à jour par Frédéric Péters il y a plus de 2 ans

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

Mis à jour par Thomas Jund il y a plus de 2 ans

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

Mis à jour par Frédéric Péters il y a plus de 2 ans

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

Mis à jour par Thomas Jund il y a plus de 2 ans

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

Mis à jour par Frédéric Péters il y a plus de 2 ans

(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

Mis à jour par Thomas Jund il y a plus de 2 ans

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

Mis à jour par Frédéric Péters il y a plus de 2 ans

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

Dedans :

#59

Mis à jour par Frédéric Péters il y a plus de 2 ans

+ 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

Mis à jour par Frédéric Péters il y a plus de 2 ans

  • Statut changé de En cours à 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

Mis à jour par Frédéric Péters il y a plus de 2 ans

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

#62

Mis à jour par Frédéric Péters il y a plus de 2 ans

  • Statut changé de Solution validée à 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

Mis à jour par Frédéric Péters il y a plus de 2 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF