display lists as images (#72176) #322
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "wip/72176-option-to-display-list-as-images"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
278e54f73a
toa1fc1cefbe
a1fc1cefbe
toc6da7d0fe8
c6da7d0fe8
to764994815f
764994815f
toed32df6059
Pourquoi avoir choisi un select ?
Utiliser une liste de boutons radios est préférable car elle permet de se passer complètement de JS et sera full accessible. HTML only.
Ensuite, je déplacerais le CSS dans un fichier dans publik-base-theme qui permet de surcharger plus simplemement si besoin et de pouvoir ajouter des vars scss de configuration.
ed32df6059
tofaf23c1c16
faf23c1c16
to130c5ffe3f
Pour les images, je pense que c'est mieux d'utiliser une balise image, cela évite la possible superposition avec le label et permet facilement de personnaliser la taille
Tous les champs de formulaire sont férrés à droite, je trouve bizarre que celui-là soit centré.
Il manque le focus au clavier sur les items, tu devrais pouvoir le récupérer avec
Et cela va necessité de bouger le code dans PBT et gadjo.
On dejà dans une logique de duplication de code des widget dans gadjo et PBT, je vois mal comment justifier de changer
Les items, la taille des images est trop importante sur mobile aussi.
@ -0,0 +45,4 @@
raise TraversalError()
class DataDirectory(Directory):
Je note déjà ça parce que critique : on ne peut vraiment pas avoir un accès aux données de fiches sans contrôle d'accès.
Je me suis trop emballé ici à donner accès à tous les fichiers.
Je vais me limiter à donner accès au fichier image si elle existe.
Je reste très peu chaud; sans encore d'idée précise mais peut-être sur le mode de l'autocomplétion, création d'un jeton à la visite sur la démarche, et accès via celui-ci, pour vraiment limiter les accès.
@ -2292,2 +2293,4 @@
position_template = None
# images options
columns_number = 4
Ici un détail mais à avoir correct dès le début pour s'éviter des migrations : columns_count, ou number_of_columns, pas columns_number.
@ -0,0 +16,4 @@
{% endfor %}
<style>
.buttons-with-images .content {
Évitons vraiment tant de styles inline (il faut ces styles dans les styles backoffice + dans publik-base-theme, où ils pourront être adaptés si nécessaire.
130c5ffe3f
tod9b5f17249
d9b5f17249
to8aac9a5e16
8aac9a5e16
to2f13a39a8a
2f13a39a8a
to36c67fb61c
@ -0,0 +2,4 @@
{% block widget-control %}
<style>
:root {
Pas de :root ici. Limiter le contexte de la variable à
.CheckboxesWithImagesWidget
@ -0,0 +2,4 @@
{% block widget-control %}
<style>
:root {
Idem, ne pas utiliser :root
@ -0,0 +16,4 @@
type="checkbox"
{% if widget.readonly %}value="yes" disabled {% else %}name="{{ option.name }}" value="yes"{% endif %}
><label for="{{ widget.get_name_for_id }}_op_{{ forloop.counter0 }}" style="max-width:{{ widget.field.image_desktop_width }}px">
{% if option.options.image_url %}<picture><img src="{{ option.options.image_url }}" title="{{ option.label }}" /></picture>{% endif %}
Pourquoi utiliser le tag ? Il ne sert à rien puisqu'on utilise pas les images adaptatives et les balises .
L'image doit avoir une balise alt vide pour indiquer qu'elle n'est que "décorative"
@ -629,0 +635,4 @@
label {
margin-bottom: 5px;
padding: 10px;
max-width: calc(var(--image-desktop-width) - 20px);
(Je n'arrive pas à insérer ici un image, je la mets en commenaire plus bas)
Branche à jour la nouvelle structure HTML et feuille de style pour assurer au maximum l'accessibilité. @tjund je veux bien ton oeil pour vérifier que je n'ai rien zappé.
Choix d'images de tailles différentes
Les images débordent aussi lorsqu'elles sont trop grandes (elles ne sont pas responsive par défaut dans gadjo)
Et je trouve bizarre ce box-shadow utilisé pour indiquer l'élément selectionné, ça sort de nul part (je veux bien regarder une alternative).
36c67fb61c
to290e62420e
290e62420e
to1c3a840fdc
@ -114,0 +120,4 @@
def get_file_url(self, file_digest):
context = {'carddef_slug': self.formdef.url_name, 'data_id': self.id, 'file_digest': file_digest}
token = get_session().create_autocomplete_token(context)
Il faudrait un nom approprié pour cette méthode, même si c'est la même infra de token qui est utilisée derrière.
@ -114,0 +121,4 @@
def get_file_url(self, file_digest):
context = {'carddef_slug': self.formdef.url_name, 'data_id': self.id, 'file_digest': file_digest}
token = get_session().create_autocomplete_token(context)
return "/api/file/%s" % token.id
Et quelque chose de moins générique comme chemin, type /api/card-file-token/, peut-être.
@ -250,3 +251,2 @@
def get_items(data_source, include_disabled=False, mode=None):
structured_items = get_structured_items(data_source, mode=mode, include_disabled=include_disabled)
def get_tuppled_items(structured_items):
tupled_items = []
Mauvais nom de méthode (cf dessous il y a un seul p), mais surtout tu peux dire deux mots sur pourquoi cette découpe supplémentaire ?
En effet, typo dans le nom de la méthode.
L'idée de la découpe est d'avoir une méthode (
get_structured_carddef_items
) pour passer un paramètre qui permet d'avoir l'url de l'image à la source de données des fiches.Et
get_tupled_items
remplaceget_items
pour le formattage:id
,text
, etc.@ -2571,0 +2588,4 @@
'image_desktop_size',
title=_('Image size on desktop'),
value=self.image_desktop_size,
validation_function=ComputedExpressionWidget.validate_template,
Cette validation est sans doute un copié/collé excessif.
@ -2700,1 +2743,4 @@
# images options
image_desktop_size = 150
image_mobile_size = 75
Il y a un mixin partagé entre ItemField et ItemsField, pourquoi ne pas y ajouter ce code commun ? (ou comme pour le partage entre MapField et ItemField, un nouveau mixin dédié pour ces options ?)
1c3a840fdc
to236ccd29fa
236ccd29fa
tob72981a19f
@ -0,0 +29,4 @@
&--picture {
margin-bottom: 5px;
grid-area: picture;
align-items: end;
align-items ne marche que sur container grid, donc inutile ici.
@ -0,0 +39,4 @@
}
&--input {
grid-area: input;
align-items: baseline;
align-items ne marche que sur container grid, donc inutile ici.
.item-with-image--input n'existe pas sur .RadiobuttonsWithImagesWidget
Les CSS s'appliquent depuis la saisie en BO, mais pas depuis la fabrique de formulaire.
Et point de détail, ou pas, je préfère une cohérence dans le nom des fichier :
Et question peut-être naive : c'est necessaire d'avoir 2 templates html à 99% identique ?
b72981a19f
to306ae6b61e
Je viens de rebaser la branche sur master pour avoir #78730 qui corrige ce souci.
Le diable est dans les détails: pour les boutons radio on a
et
pour les checkbox:
et
Partir sur un
include
ou autre ne réduira pas le nombre de fichiers.306ae6b61e
tobbde0f1b24
WIP: display lists as images (#72176)to display lists as images (#72176)@ -431,0 +431,4 @@
class CardFileByTokenDirectory(Directory):
def _q_lookup(self, component):
get_request().ignore_session = True
context = get_session().get_autocomplete_token(component).data
Il faudrait un nom approprié pour cette méthode, même si c'est la même infra de token qui est utilisée derrière.
Je me suis embourbé à appeler
get_autocomplete_token
alors queget_by_magictoken
existe déjà.@ -307,0 +310,4 @@
def has_image_field(self):
for f in self.fields:
if not f.key == 'file' or f.varname != 'image':
continue
Je trouve cette combinaison avec le not == et le != est peu lisible; pour moi ça serait plus lisible d'exprimer ce qui est souhaité,
T'as raison. C'est corrigé.
bbde0f1b24
toc165fb3b84
@ -0,0 +14,4 @@
}
.item-with-image {
margin-bottom: 5px;
margin-bottom devenu inutile parceque display grid
Merci, c'est retiré.
À part ma dernière demande concernant le margin à supprimer, c'est ok pour moi
c165fb3b84
todc9d6f2ab1
dc9d6f2ab1
to0b7861fad9
Vu avec @tjund par jabber: on va passer les tailles de l'image en attribut de la balise du widget pour avoir un code HTML valide.
0b7861fad9
toc877f090d4
@ -0,0 +8,4 @@
--image-size: var(--image-desktop-size);
}
&:focus-within {
outline: 1px dashed var(--primary-color);
D'où arrive
var(--primary-color)
? Il manque un ticket côté publik-base-theme ?On s'est basé sur le rendu en backoffice où la variable
--primary-color
est déjà disponible.Et quand ça sera disponible côté front le widget gagnera automatiquement le focus.
Ça demande a minima qu'un ticket soit créé, ça ne va pas arriver tout seul.
Et quel est donc le comportement actuel en front, pas de focus du tout (= problème d'accessibilité) ou un focus d'une mauvaise couleur ?
Pas de focus du tout. J'ai rajouté un fallback vers un gri clair mais il faudrait le gérer côté publik-base-theme pour utiliser plutôt
$widget-focus-outline
. Je fais le ticket.@ -0,0 +17,4 @@
{% endfor %}
{% endblock %}
(ligne blanche perdue)
@ -0,0 +2,4 @@
{% block widget-attrs %}
{{ block.super }}
style="--image-desktop-size: {{ widget.field.image_desktop_size }}px;--image-mobile-size: {{ widget.field.image_mobile_size }}px;"
Ça va clasher avec le cas où le champ est conditionné/caché, qui ajoute déjà un
(pareil pour le cas checkboxes)
Ici je ne vois pas d'autres options que de revenir à la declaration CSS dans le template du widget:
J'aurais dû l'écrire, je pensais plutôt qu'on pourrait introduire un
{% block widget-style-attribute %}
et dedans alors il y aurait la gestion du cas champ caché, et dans le gabarit des images ça serait récupérer via block.super.J'y ai pensé aussi, mais j'hésitais à toucher au template des widgets.
Je le fais.
c877f090d4
to5dae8c62cf
5dae8c62cf
to991fca2bf6
991fca2bf6
to0912aa68f9
0912aa68f9
todb0a6c656f