Development #52073
composition graphique grille fiche
0%
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
Demandes liées
Révisions associées
Historique
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.
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.
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).
Mis à jour par Thomas Jund il y a environ 3 ans
- Lié à Development #52336: nouveau system de grille en flexbox ajouté
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.
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é
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.
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.
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).
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).
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.
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…
Mis à jour par Thomas Jund il y a presque 3 ans
- Fichier 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch ajouté
- Statut changé de En cours à Solution proposée
- Patch proposed changé de Non à Oui
branch rebase et patch
Mis à jour par Thomas Jund il y a presque 3 ans
- Lié à Bug #53778: manager JS: scope global pour compute_max_height ajouté
Mis à jour par Thomas Jund il y a presque 3 ans
- Lié à Development #53780: manager JS: ajout des events cell:open & cell:close ajouté
Mis à jour par Frédéric Péters il y a presque 3 ans
- Fichier Screenshot_2021-05-11 Portail Agent.png Screenshot_2021-05-11 Portail Agent.png ajouté
- Statut changé de Solution proposée à En cours
- Patch proposed changé de Oui à Non
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 ?
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" />
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.
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.
Mis à jour par Thomas Jund il y a presque 3 ans
- Fichier 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch ajouté
- Statut changé de En cours à Solution proposée
- Patch proposed changé de Non à Oui
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 #}
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.
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 ?
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.
Mis à jour par Thomas Jund il y a presque 3 ans
- Lié à Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden] ajouté
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
Mis à jour par Thomas Jund il y a presque 3 ans
- Lié à Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden] supprimé
Mis à jour par Thomas Jund il y a presque 3 ans
- Bloqué par Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden] ajouté
Mis à jour par Thomas Jund il y a presque 3 ans
- Fichier 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch ajouté
- Statut changé de En cours à Solution proposée
Patch dispo pour relecture
Mis à jour par Thomas Jund il y a presque 3 ans
- Bloqué par Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden] supprimé
Mis à jour par Thomas Jund il y a presque 3 ans
- Lié à Development #54259: cellule fiche: ajouter checkbox "personnaliser" et input (hidden] ajouté
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,
Mis à jour par Thomas Jund il y a presque 3 ans
- Fichier 0001-card-cell-display-customize-content-layout-52073.patch 0001-card-cell-display-customize-content-layout-52073.patch ajouté
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
Mis à jour par Thomas Jund il y a presque 3 ans
- Lié à Bug #54911: suppresion balise sur selecteur .label ajouté
Mis à jour par Thomas Jund il y a presque 3 ans
- Fichier 0001-card-infos-cell-form-add-i18n-52073.patch 0001-card-infos-cell-form-add-i18n-52073.patch ajouté
patch i18n.
Branch rebasé et à jour.
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 :
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 #}
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.
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.
Mis à jour par Thomas Jund il y a plus de 2 ans
- Fichier 0002-card-cell-display-customize-content-layout-52073.patch 0002-card-cell-display-customize-content-layout-52073.patch ajouté
- Fichier 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch 0001-card-infos-cell-form-add-UI-to-customize-content-lay.patch ajouté
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
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à).
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'
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'
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 ?
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.
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é".
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".
Mis à jour par Thomas Jund il y a plus de 2 ans
- Fichier one-field-in-grid-cell-form.png one-field-in-grid-cell-form.png ajouté
- Fichier multi-fields-in-grid-cell-form.png multi-fields-in-grid-cell-form.png ajouté
Ça se ferait en améliorant le formulaire d'ajout/modification d'une cellule de grille en permettant de choisir plusieurs champs de fiche.
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.
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.
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.
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.
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.
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.
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 :
- correction sur l'orthographe de schema, qui se trouvait shema à certains endroits, https://git.entrouvert.org/combo.git/commit/?h=wip/52073-card-cell&id=e2720150af3ab2636153951585ad07e8091da199
- suite de l'internationalisation, il restait des chaines en dur en français, https://git.entrouvert.org/combo.git/commit/?h=wip/52073-card-cell&id=e59af09d9910f6eb1b685c2114a5907a3847390f (le premier chunk du patch n'a rien à faire là mais comme l'intention est de squasher le tout après je l'ai laissé)
- ce dont on parlait plus haut, le remplacement de l'attribut liste display par un attribut display_mode, https://git.entrouvert.org/combo.git/commit/?h=wip/52073-card-cell&id=076fec086eef9492cd7cf817557e67f067f487d3 , qui peut prendre les valeurs label-and-value, label, value, title. Aussi à travailler là-dedans je me suis rendu compte qu'on stockait et on utilisait une traduction pour la taille du champ, plutôt que prendre le libellé correspond au choix au moment du rendu, c'est corrigé. Et dans ce commit aussi j'ai vu qu'il y avait des bouts d'anglais et des bouts de français intégré dans le fichier css, c'est viré remplacé correctement.
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.
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)
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Fichier Screenshot 2021-07-26 at 16-35-29 Services en ligne.png Screenshot 2021-07-26 at 16-35-29 Services en ligne.png ajouté
Pour référence par rapport aux ~captures tapées dans le ticket aujourd'hui ça ressemble à celle-ci.
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)
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
wcs: add support for custom content layout (#52073)