Project

General

Profile

Development #38328

Le type des paramètres get affiché sera toujours 'string'

Added by Valentin Deniaud about 1 month ago. Updated about 1 month ago.

Status:
Solution proposée
Priority:
Normal
Target version:
-
Start date:
09 Dec 2019
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

Description

Dans #37481 :

Le rendu des paramètres "classiques" (query-string) est aussi modifié :
  • ajout du type (par défaut "string", float et integer sont possibles)

C'est pas bien vrai, il a été ajouté

+ <b class="type">{% if param.type %}{{ param.type }}{% else %}string{% endif %}</b>

Sauf que ce param.type n'est jamais rempli nulle part.

Ce ticket est donc un prérequis pour pouvoir parler de #38276, #38277 et #38279, mais j'ai dans l'idée que sa résolution va en fermer certains.

0001-utils-include-type-of-params-in-endpoint-documentati.patch View (2.05 KB) Valentin Deniaud, 09 Dec 2019 05:53 PM

0001-utils-try-to-guess-type-of-params-38328.patch View (5.28 KB) Valentin Deniaud, 10 Dec 2019 10:59 AM

0001-utils-try-to-guess-type-of-params-38328.patch View (5.24 KB) Valentin Deniaud, 10 Dec 2019 12:02 PM


Related issues

Related to Passerelle - Development #38279: paramètre booléen de query string annoncé de type "string" Nouveau 07 Dec 2019

History

#1 Updated by Valentin Deniaud about 1 month ago

#2 Updated by Valentin Deniaud about 1 month ago

Je suis pas sûr de la détection automatique, c'est beaucoup de demie mesure. Le bon côté c'est que ça résout #38279 sans toucher à rien, et que potentiellement ça résout ce type de problème dans d'autres connecteurs. Le mauvais c'est que renseigner le type des paramètres dans @endpoint fait bénéficier de validation, et ce genre de bidouille dissuade à tord de le faire.

#3 Updated by Frédéric Péters about 1 month ago

Le mauvais c'est que renseigner le type des paramètres dans @endpoint fait bénéficier de validation.

Mais il devrait là aussi y avoir validation; je dirais que @endpoint() doit alimenter son self.parameters de la manière la plus automatique possible, et que cette info soit ensuite exploitée.

Vite fait à peine testé :

--- a/passerelle/views.py
+++ b/passerelle/views.py
@@ -320,10 +320,12 @@ class GenericEndpointView(GenericConnectorMixin, SingleObjectMixin, View):
                 d[key] = other_params[key]
         if self.endpoint.endpoint_info.parameters:
             # check and convert parameter values
-            for parameter, parameter_info in self.endpoint.endpoint_info.parameters.items():
+            import pdb; pdb.set_trace()
+            for parameter_info in self.endpoint.endpoint_info.get_params():
+                parameter = parameter_info['name']
                 if parameter not in d:
                     continue
-                if parameter_info.get('type') == 'bool':
+                if parameter_info.get('type') in ('bool', 'boolean'):
                     if d[parameter].lower() in ('true', 'on'):
                         d[parameter] = True
                     elif d[parameter].lower() in ('false', 'off'):

(la vérif sur bool & boolean étant malheureuse, mais vu que ça a gagné un second nom sur la route…)

#4 Updated by Frédéric Péters about 1 month ago

  • Related to Development #38279: paramètre booléen de query string annoncé de type "string" added

#5 Updated by Valentin Deniaud about 1 month ago

Bonne idée. Juste que lier ce type de détection à la validation comporte un risque (genre un coord_x=1 qu'on détecte en int mais qui peut prendre des floats, voire des strings si on joue aux échecs ('1A'), bref des risques de régressions difficilement prévisibles qui seront découvertes en prod, à moins de faire le tour de tous les connecteurs).

À part ça tant qu'à faire, j'étends la déduction à example_value.

#7 Updated by Valentin Deniaud about 1 month ago

(avec un #todo survivant en moins)

Also available in: Atom PDF