Produits Entr'ouvert » Passerelle

Je suis parti d'un connecteur de type "donnée" (opendatasoft et j'ai laissé la recherche sur q/id).

J'ai ajouté un champ "meta" au retour des appels sur les requêtes qui indique le nom et la description de l'objet requête (pour les afficher dans la tuille).

Oui (fait).

J'ai retiré l'authentification basique au profit de l'authentification OIDC.
Je table sur le fait qu'actuellement on n'en a pas besoin (#57755) et qu'à terme tout passera par OIDC.

Bien que l'authentification OIDC soit spécifique à Imio, j'ai laissé le connecteur dans "apps" parce que la partie requête de recherche peut toujours s'utiliser de façon anonyme.

• connecteur copié depuis opendatasoft, pour avoir des objets Query très similaires.
• connection OIDC avec token copié depuis lille_kimoce.
• système CRUD copié depuis esirius.
• payload du post et du put sans schéma comme sur greco.

Le connecteur est documenté ici :
https://dev.entrouvert.org/projects/braine-l-alleud/wiki/Plone_REST_API

Il manque autour de ça des commentaires et peut-être des meilleurs noms de méthodes pour expliciter ce que c'est supposé faire.

C'est pour éviter ces complications dans combo
https://dev.entrouvert.org/issues/51764#note-15

<a href="{{actu|get:'@id'}}">

Mais aussi parce que pour passer ces champs dans la query string vers Plone il faut les renommer de la sorte.
https://dev.entrouvert.org/issues/51764#note-9

https://conseil.staging.imio.be/@search?portal_type=Meeting

Dans le payload, Plone accepte les 2 syntaxes. J'ai trouvé plus cohérent de renommer les clés partout.
J'ai essayé d'être plus explicite dans le code/commentaires.

c'est du code pour éviter un double-slash quelque part

oui, et pour gérer les paramètres vides (j'ai simplifié).

Il faut quand même pas trop copié/collé,

J'ai modifié :

filter_expression -> 'Specify more URL parameters (key=value) separated by lines'

Il faut arrêter avec six, on ne fait plus que du python3.
c'est peu clair d'utiliser [3], on gagne vraiment en compréhension à plutôt faire .query.

Fait.

sort de nulle part. (?)

Un oubli, merci.

Je crains que ça n'amène plus de confusion qu'autre chose, sauf impossibilité (à exprimer) je ferais vraiment sans.

Merci, je me suis trompé : il faut nécessairement passer '@truc' dans le payload (ici testé avec "portal_type") :

{'message': "Property '@type' is required", 'type': 'BadRequest'}

Pour la récupération des champs 'truc' dans combo et wcs, je vois un endroit où ça pourrait coincer : dans le gabarit du connecteur où l'on ne dispose pas du filtre @get.
Aussi, wcs ne reconstruit pas de variable qui permet d'atteindre des valeurs dont le chemin contient des des clé préfixées par des '@'.
Je propose de laisser le renommage des clé de Plone, là où l'on fait la normalisation.

Par contre cela m'amène à un autre point que j'ai zappé.
Dans wcs, pour passer des dictionnaires et des tableaux je dois faire "unflatten" sur le payload.

Dans https://dev.entrouvert.org/attachments/58388 qui est ton script d'envoi d'infos, ça envoie une clé title, pas @title.

(je ne comprend pas à quoi fait référence la clé @title)

Ça m'a l'air encore totalement confusion. Le fichier de test qui ne correspondent pas du tout à nos cas pratiques n'aide pas.

Fait. Ça me permet d'ajouter des données de test qui contiennent un exemple avec de la geolocalisation et des d'horaires.

S'il fallait un truc, je serais pour quelque chose de bien explicite :
noter que les clés @id et @type qui peuvent se trouver dans les réponses de plone sont converties en clés PLONE_id et PLONE_type

Fait en commentaire.

1/ on explicite les clés concernées, on annonce qu'on ne va pas aller modifier n'importe quoi,

Cela concerne uniquement les clé qui commencent par '@', mais oui, ici il n'y en a que 3 : '@id', '@type' et '@components'.
Je les ai posées dans une variable.

2/ on explicite le changement que ça amène et on met un changement qui est bien clair, genre PLONE_ plutôt que portal_ qui ne signifie rien.

Oui, PLONE_ pour la réponse ; portal_ c'est pour la query-string, ça n'a rien à voir ici.

Qu'il soit clair aussi que j'ai une détestation assez tenace du mot "normalize" qui veut juste rien dire, donc quand je répète explicite ci-dessus, c'est aussi pour encourager un nom de méthode explicite, genre adapt_id_and_type_plone_attributes.

Fait.

Dans wcs, pour passer des dictionnaires et des tableaux je dois faire "unflatten" sur le payload.
On gagnerait à un exemple pratique. (je ne vais pas creuser)

C'est ma faute, je ne me suis mal relu : je dois faire -> je fait à présent appel à "unflatten"
cf test_create :

    payload = {
        'topics/0/title': 'Tourisme',
        'topics/0/token': 'tourism',
    }

Ce n'est pas encore testé localement (je suis en train de le faire mais c'est long) via wcs, mais je suis plutôt confiant.

Zut, grosse typo de corrigée 'addapt' -> 'adapt'.

[ici des commentaires]

Mais on n'a pas le temps, fuck it ça sera des corrections.

commit 7fc18248dd700365f008d2b7ddefd9c4b35c2a15
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date:   Tue Sep 21 17:16:06 2021 +0200

    plone-restapi: add a plone.restapi connector (#57258)