Produits Entr'ouvert » Combo

Comme discuté sur la liste.

Reprendre ce qui y a été dit, parce que là on ne sait visiblement pas quoi faire.

avoir juste la version simple on/off m'irait assez bien

• sur la carte visible non loggué dans combo (https://mesdemarches-fsb.test.entrouvert.org/tests/test-carto/)
• au clic sur une puce s'afficherait les deux valeurs enregistrées dans "typologie signalements" et "statut simplifié" (https://stats-fsb.test.entrouvert.org/visualization/14/geojson/)
  OK pour moi

Un simple template moustache pour le contenu des vignettes et puis basta, non ?

au clic sur une puce s'afficherait les deux valeurs enregistrées

Les deux valeurs uniquement, ou également des libellés ? Et dans quel ordre ? (ici par hasard ça affiche typologie signalement avant statut simplifié, mais ça n'est défini nulle part)

Et s'il faut afficher des libellés, ceux-ci seraient les textes du json, et donc "statut simplifié", un peu obscur, et triste de sa majuscule perdue ?

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

Les deux valeurs uniquement

pour faire simple, oui suffit

ou également des libellés ?
Et s'il faut afficher des libellés, ceux-ci seraient les textes du json, et donc "statut simplifié", un peu obscur, et triste de sa majuscule perdue ?

si on décide d'afficher les libellés alors impliquerait de pouvoir les modifier, oui

Et dans quel ordre ? (ici par hasard ça affiche typologie signalement avant statut simplifié, mais ça n'est défini nulle part)

Si l'ordre découle du GéoJSON (regroupement horizontal en premier ou vertical en 2ème, ou inversement) permettrait de décider en amont et tant mieux.
Si ne peut être choisi, dans mon cas d'usage de Fontenay, pas grave, à condition que l'ordre soit toujours le même sur chacune des icônes.

Les deux valeurs uniquement

pour faire simple, oui suffit

Mais sans libellés, au-delà de deux valeurs, ça va vite devenir un truc incompréhensible.

Si l'ordre découle du GéoJSON

Non, il ne définit pas d'ordre.

Si ne peut être choisi, dans mon cas d'usage de Fontenay, pas grave, à condition que l'ordre soit toujours le même sur chacune des icônes.

Ça veut alors dire trier sur base des libellés (alphabétiquement a priori).

Quelques commentaires plus haut l'opinion de Brice est de ne pas afficher le nom des attributs en tant que libellés. (et mon avis est qu'à un moment c'est quand même important d'afficher des libellés mais les noms de propriétés ne sont pas adaptés).

Ok je comprends, mais je pense quand meme utile de les avoir de les avoir des maintenant.

Il faut alors du code pour pouvoir assurer une correspondance entre libellés et propriété. Ce qui est bien c'est qu'en même temps ça permettra de gérer l'ordre d'affichage.

Attention Serghei aussi est occupé à ajouter une migration sur ce modèle, c'est plutôt malheureux de se trouver à se marcher sur les pieds alors qu'il y a mille choses à faire.

    display_marker_data = models.BooleanField(default=False, verbose_name=_('Display marker data'))

Des échanges sur la liste je préférerais anticiper un rien et avoir un marker_onclick_behaviour, qui serait une liste de possibilités, aujourd'hui ('rien', 'affichage des infos dans une popup'), plus tard d'autres options.

                                        popup += '<p class="popup-field"><span class="field-label">' + value + '</span>' + '</p>';

Tu ne peux pas utiliser une classe field-label et mettre dedans une valeur et te dire que c'est logique.

         data-display-marker-properties="{{ cell.display_marker_data }}" 

En suivant ma première remarque sur marker_onclick_behaviour, cette remarque sera obsolète mais ici, data-whatever="True" (parce que repr() du bool()), c'est interprété correctement par le javascript ?

>>> $('[data-plop]').data('plop')
"False" 
>>> if ($('[data-plop]').data('plop')) console.log('fail')
fail

Et noté dans ce ticket, il faut assurer un ordre stable pour les propriétés, il n'y a rien de particulier fait ici, $.each(feature.properties(... va les prendre dans je ne sais quel ordre; tu as une référence pour dire que c'est bon deux objets javascript énumèrent toujours leurs propriétés dans un ordre identique ?

Ta migration est en conflit avec celle de Serghei, j'avais prévenu.

){

Très sérieusement, je ne vais plus relire les patchs où il n'y a pas un minimum d'application sur le style.

                                let properties = Object.keys(feature.properties).sort().reduce(function(new_prop, key) {
                                    new_prop[key] = feature.properties[key];
                                    return new_prop;
                                }, {});

rly?

                                $.each(properties, function(key, value) {

properties reste un Object (et j'ai du exécuter le code au-dessus pour le vérifier, si peu lisible); quelle garantie que sur cet Object, mais pas le précédent, les propriétées soient lues par ordre alphabétique ?

Tu utilises quelle source pour tes geojson de test ? (la question étant : te garantit-elle que les valeurs seront échappées pour être ainsi tapées dans l'html ?)

                                     popup += '<p class="popup-field"><span class="field-value">' + escape(value[1]) + '</span>';

escape() / Obsolète / Cette fonctionnalité a été supprimée des standards du Web. Bien que quelques navigateurs puissent encore la supporter, elle est en cours d'éradication. Ne l'utilisez ni dans d'anciens projets, ni dans de nouveaux. Les pages et applications Web l'utilisant peuvent cesser de fonctionner à tout moment. — https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Objets_globaux/escape

_~~

Il y avait quand même du vrai dans la question sur l'origine de tes sources geojson de test, parce qu'à part la vue geojson d'un formulaire spécifique dans w.c.s., je ne vois pas où tu trouverais feature.properties.display_fields, mais si c'est w.c.s., les valeurs sont échappées.

escape() / Obsolète / etc.

Et à vérifier, totalement inadapté, si j'ai une valeur "film untel (> 16ans)", je veux que "film untel (> 16ans)" s'affiche, pas "film%20untel%20%28%3E%2016ans%29".

_~~

Avec ton exemple où "Voirie et espace public" apparaît, ça aurait pourtant du te sauter aux yeux que ça n'allait pas. (?)

Il y avait quand même du vrai dans la question sur l'origine de tes sources geojson de test, parce qu'à part la vue geojson d'un formulaire spécifique dans w.c.s., je ne vois pas où tu trouverais feature.properties.display_fields, mais si c'est w.c.s., les valeurs sont échappées.

Pour repondre a ta question en attendant de poser un patch, mes sources geojson de test viennent à la fois de w.c.s et de bijoe.

Ajout d'une function qui échappe les caractères quand il le faut

Non, jamais tu n'arriveras à déterminer "quand il le faut" (ni toi, ni personne). Ici w.c.s. va répondre avec un <a href="...">fichier.pdf</a> et tu vas échapper ça et plouf. Si j'ai créé le ticket #22031 côté w.c.s., c'est bien parce que ce n'est pas côté navigateur qu'on peut deviner les choses.

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

Ajout d'une function qui échappe les caractères quand il le faut

Non, jamais tu n'arriveras à déterminer "quand il le faut" (ni toi, ni personne). Ici w.c.s. va répondre avec un <a href="...">fichier.pdf</a> et tu vas échapper ça et plouf. Si j'ai créé le ticket #22031 côté w.c.s., c'est bien parce que ce n'est pas côté navigateur qu'on peut deviner les choses.

Je ne comprends pas bien, l'échappement coté serveur ou navigateur ne serait pas identique ?

In [4]: django.utils.html.escape('<a href="https://whatever.com">whatever</a>')
Out[4]: u'&lt;a href=&quot;https://whatever.com&quot;&gt;whatever&lt;/a&gt;'

Ou bien ce que tu veux dire, c'est de juste le faire en backend combo lorsque l'on récupère les sources ?

Enfin, j'ai juste suivi ce que l'on a décidé hier. J'ai peut etre mal compris ce qui a été dit alors.

Je ne comprends pas bien, l'échappement coté serveur ou navigateur ne serait pas identique ?

Le serveur connait la nature de ce qu'il sert. Le client ne connait pas la nature de ce qu'il reçoit (juste une chaine).

Côté client, si tu reçois :

• Une chaine "<script>alert('hello')</script>', tu l'échappes ou pas ?
• Une chaine "<a href=...>plop.pdf</a>', tu l'échappes ou pas ?

Il y a deux mois : « Ici w.c.s. va répondre avec un <a href="...">fichier.pdf</a> et tu vas échapper ça et plouf ».

Plus tôt encore, #22031 du côté de w.c.s.

Pour reprendre, aujourd'hui, le client (que ça soit le navigateur ou combo client de w.c.s. quand il en reçoit les données), ne peut pas savoir ce qu'il faut échapper. Ne pourra jamais le savoir. Il faut mettre en place #22031. À partir de là, et à partir de là seulement, il deviendra possible au client de savoir que, pour le cas particulier de l'attribut nommé "html_value", décidé par convention, il n'y aura pas d'échappement à faire.

Et ça, dans le js, sur la forme :

for (...) {
  $value_elem = $('<span class="...">');
  if (whatever.html_value) {
    $value_elem.html(whatever.html_value);
  } else {
    $value_elem.text(whatever.value);
  }
}

Dès le premier écran, je ne suis pas allé plus loin, Marker behaviour on clik.

Misère, toujours premier écran, pas allé plus loin, la même erreur mais cette fois en majscules. MARKER_ONCLIK_BEHAVIOUR.

Si quelqu'un trouve la capture attachée utile, qu'il compte présenter ça à des clients, qu'il l'écrive ici. De mon côté je notais il y a quatre mois "au-delà de deux valeurs, ça va vite devenir un truc incompréhensible", bref j'ai fait mon taf de relecture technique, et comme je trouverais encore à redire, il est grand temps que j'arrête.

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

Si quelqu'un trouve la capture attachée utile, qu'il compte présenter ça à des clients, qu'il l'écrive ici. De mon côté je notais il y a quatre mois "au-delà de deux valeurs, ça va vite devenir un truc incompréhensible", bref j'ai fait mon taf de relecture technique, et comme je trouverais encore à redire, il est grand temps que j'arrête.

On en avait discuté et c'est ce que les CPF voulaient.

Je ne vois pas de réponse à mon "Mais sans libellés, au-delà de deux valeurs, ça va vite devenir un truc incompréhensible."; peut-être qu'avec la capture présentée il se dira qu'en fait non, ce n'est pas présentable. Ou pas. Ou il fallait juste quelque chose et on s'en fout de la qualité et c'est pour ça que je note que j'arrête ici.

Ce que propose Brice ma parait bien.
Juste, si ces marqueurs doivent également être utilisés en front, s'assurer que le statut affiché est bien visible par l'usager.

Par rapport au ticket wcs pointé, sur les règles CSS pour l'affichage de l'image, il aurait fallu les reprendre, plutôt qu'en faire une version minimaliste ici, avec son risque de débordement en cas de photo en mode portrait, par exemple.

Dans le code js qui n'est pas if feature.properties.display_fields, il y a $popup_field.find mais $popup_field n'est pas définie. Il serait à mon sens utile de poser sur le p.popup-field une classe avec le nom de l'attribut, pour au moins permettre, sans code, juste avec de la CSS, de cacher des propriétés.

ok pour moi. (pas testé, juste relu le ticket et le patch)