Produits Entr'ouvert » Passerelle

Et j'anticipe sur un éventuel "mais pourquoi pas intégrer python-jsonschema de façon plus générique à travers endpoint" : il me semble plus raisonnable de se servir de cette librairie 2 ou 3 fois, d'en comprendre les limites et le bon usage, avant de vouloir en faire un passerelle first-class citizen.

python-babel : pour pouvoir transformer "18/06/2018" en "lundi 18 juin 2018" sans sombrer dans la folie du module 'locale' de la lib standard.

Bof, Django gère ça sans dépendance supplémentaire.

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

python-babel : pour pouvoir transformer "18/06/2018" en "lundi 18 juin 2018" sans sombrer dans la folie du module 'locale' de la lib standard.

Bof, Django gère ça sans dépendance supplémentaire.

Je veux bien un pointeur sur comment faire ça, parce que sur recette passerelle rouen par exemple (passerelle-manage tenant_command shell):

import datetime
from django.utils import dateformat
dateformat.format(datetime.datetime.now(), 'jS F Y H:i')
u'19th June 2018 17:23'

Les commandes de gestion ne prennent pas la locale. (c'est modifié dans une version récente).

Ce n'est pas ce qu'il y a de plus joli comme lib de validation python-jsonschema mais il n'y a rien d'autre dans jessie... (ok pour là, mais pour le futur ce serait bien d'avoir un truc plus pythonic genre marshmallow ou les serializer DRF).

Frédéric : "le truc vraiment bien, ça serait de faire avancer un peu le passerelle/soap.py, que tu puisses l'utiliser."

Et donc ce sera soit #16104 soit #24675 mais ça va prendre un peu de temps, et il faut sortir une première version ici pour démo toulouse : review please !

Pour moi on ne peut plus accepter du code faisant du soap sans infra commune, il faut vraiment arrêter, #13221 a presque deux ans.

La "bonne" nouvelle c'est que Josué dans #24573 ajoute lui-aussi du nouveau code spécifique à son connecteur plutôt que travailler à l'infra commune, tu n'es pas tout seul à pouvoir faire bouger les choses.

Et vraiment, je n'ai pas d'exigence importante, je ne demande pas à ce que les connecteurs existant soient migrés dès maintenant, pas non plus que ça soit passerelle/soap.py qui serve de base, ça peut être passerelle/utils/soap.py, avec dedans une classe Client avec comme seule particularité d'accepter l'instance d'un connecteur dans son constructeur, liée à une classe Transport qui recevrait celui-ci et utiliserait le connecteur.requests pour faire les appels.

Ajout d'une note dans #16104, préalable toujours important à mon sens.

Ack.