Produits Entr'ouvert » w.c.s.

Dans le travail en cours sur les blocs de champs il y a un **kwargs ajouté de manière systématique aux méthodes get_view_value(), ça permettra de distinguer les situations mieux qu'aujourd'hui, d'avoir un rendu là dans la vue de traitement d'une demande différent de ce qui est affiché dans une colonne du tableau de traitement.

(ça peut déjà être possible aujourd'hui via la distinction get_view_value et get_short_view_value mais je déconseille d'avancer là-dessus avant les blocs de champs).

Constatation empirique que sur la page de résumé la méthode est appelée avec un value_id contrairement à la page de tableau.

Oui ce n'est pas nécessairement bien nommé "value_id", c'est nommé ainsi en pensant uniquement aux champs liste; ça vient de get_value_info() dans wcs/fields.py,

        # return the selected value and an optional dictionary that will be
        # passed to get_view_value() to provide additional details.

En pratique pour une liste à choix multiples ce qui se trouve mis dans "value_id" c'est la valeur "raw", la liste des choix.

J'écris "la liste des choix", sur un champ alimenté par une source de données, c'est plus précisément la liste des identifiants des choix, i.e.

+            for x in kwargs['value_id']:
+                r += htmltext('<li>%s</li>' % x)

va afficher 1 et 4, plutôt que "pomme" et "abricot".

Dans le get_value_info sont passées toutes les données disponibles, il y aurait dans le cas de la liste à choix multiples à en extraire les libellés individuels, qui peuvent se trouver, le stockage étant :

{'1': ['1', '4'],
 '1_display': 'Pomme, Abricot',
 '1_structured': [{'id': 1, 'text': 'Pomme', 'nom': 'Pomme'}, {'id': 4, 'text': 'Abricot', 'nom'': 'Abricot'}],
 etc.

(il y a cependant à vérifier que la colonne _structured est bien enregistrée pour les sources de données qui contiennent juste id et text et pas d'attributs supplémentaires).

Non ce n'est pas le cas, mais pas très gênant, ça se gère comme le cas sans data source.

C'est-à-dire que ça va afficher une liste d'identifiants plutôt que des libellés ?

Non ça va afficher les libellés.

La situation avant ce patch sur les paramètres reçus par get_view_value sur une page de résumé :

• pour une des choix rentrés manuellement ('foo', 'bar') ou venant d'une source de donnée "simple" (avec juste 'id' et 'text' : [{'id': '1', 'text': 'foo'}, {'id': '2', 'text': 'bar'}]) ça donne

value = 'foo, bar'
value_id = ['foo', 'bar']

(avec aucune donnée en plus dispo via get_structured_value dans le cas de la source de donnée simple)

• pour une source de donnée "complexe" [{'id': '1', 'text': 'foo', 'whatever': 'xxxx'}, {'id': '2', 'text': 'bar', 'whatever': 'zzz'}], ça donne

value = 'foo, bar'
value_id = ['1', '2']

mais avec des infos dispos en plus via get_structured_value.

Du coup le patche consiste juste à surcharger get_value_info pour avoir les libellés de dispo via un argument text dans le cas source de donnée complexe et d'aller piocher dans text ou value_id selon le cas.

Ma question porte sur :

(il y a cependant à vérifier que la colonne _structured est bien enregistrée pour les sources de données qui contiennent juste id et text et pas d'attributs supplémentaires).

i.e. le cas où il y a une source de données, qui serait [{'id': '1', 'text': 'foo'}, {'id': '2', 'text': 'bar'}].

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

Ma question porte sur :

(il y a cependant à vérifier que la colonne _structured est bien enregistrée pour les sources de données qui contiennent juste id et text et pas d'attributs supplémentaires).

La réponse est non, pas de colonne _structured enregistrée dans ce cas, mais dans ce cas toujours la liste des libellés est passée dans value_id (déjà le cas avant ce patch), donc j'ai juste à piocher dedans.

J'observe que ça fait échouer des tests qui vérifient l'absence de cette donnée, ça semble facile corriger, mais zéro hauteur de vue sur cette situation, est-ce la voie à suivre ?

Je dirais que oui, ça me semble avoir été fait ainsi en pensant uniquement au type "liste" et pour économiser un peu de données. (origine de tout ça dans #7466).

Pour le reste du patch ambitions revues à la baisse : afficher sous forme de liste uniquement si on a le _structured à disposition

C'est-à-dire "pas pour les anciennes demandes", right ?

Ok, sans doute unir 0002 & 0003 en un seul commit et ajouter une classes sur le <ul> pour ne pas cibler large.