Produits Entr'ouvert » Passerelle

Comme cityweb est une vraie application et pas quelque chose de spécifique à Orléans, la mettre dans passerelle.apps (surtout si derrière c'est pour l'activer tout le temps).

CANALS = [
    {"id": "internet", "text": "Internet"},
    {"id": "guichet", "text": "Guichet"},

Je veux bien passer sur les "text" qui ignorent gettext mais CANALS, quand même, faudrait traduire.

        verbose_name = "CityWeb - Demande d'acte d'etat civil" 

état.

    @endpoint(serializer_type='json-api', perm='can_access')
    def titles(self, request, without=''):
        return TITLES

Ici et dans d'autres endpoints type "source de données", pourquoi json-api ?

PASSERELLE_APP_CITYWEB_ENABLED = True

Ce n'est plus nécessaire.

@mock.patch('passerelle.contrib.cityweb.utils.get_resource_base_dir', CITYWEB_TEST_BASE_DIR)
def test_demand_creation(app, setup, payload):
    if 'naissance' in payload:
        pass
    elif 'mariage' in payload:
        pass
    else:
        pass

Pas vraiment de sens d'avoir ce test vide, il me semble.

        demand, created = Demand.objects.get_or_create(resource=self, demand_id='demand_id',
                                                       kind='kind')

Mais ça va toujours donner la même demande; il y a un bug ici.

0002-cityweb-add-template-15883.patch aucun sens à être isolé.

0003, 0004, pareil.

0005-cityweb-add-json-to-xml-converter-function-15883.patch

Encore une nouvelle manière de gérer de l'xml dans Passerelle, variation autour d'un thème imposé, chouette. (NON!)

De loin on dirait que ça copie/colle mdel et retire/ajoute une méthode différente (pour l'ElementFactory) et ajoute une gestion des namespaces dans le json_to_xml. Le code ne peut pas être partagé ?

0006-cityweb-add-demands-processing-15883.patch, enfin, du code, là ça ne sert vraiment à rien d'avoir six patchs pour le tout, pas de la sorte en tout cas. (vraiment "Demand" existe mais ne sert à rien dans 0001 et puis voilà 0006 et là il sert enfin mais soudainement on découvre que le modèle doit changer, donc une phase 1 où on aurait pu réfléchir au modèle qu'il soit bon dès le début, c'est même pas ça).

(et je ne parle pas des migrations)

Tape tout ça dans un commit unique, tape ça dans une branche, on ne pourra pas relire autrement.

Commentaire sur le reste plus tard, et ne rien faire là-dessus pour le moment mais quand même, je n'aime vraiment pas ce code de génération XML, ce mapping.py illisible. Écrit à la main ? quelle souffrance. Généré automatiquement ? ne devrait pas être dans le dépôt. Un peu des deux ? inmaintenable.

Il y a des gros bouts qui sont là pour ? (rien ?) (pourquoi en commentaire)

    # # <evenement><interesse><pere><noms><nomDeFamille>
    # ("concerned_father_names_family", "evenement_interesse_pere_noms_nomDeFamille"),

    # <demandeur><qualiteDemandeur>
    ("applicant_kind", "demandeur_qualiteDemandeur"),

De manière générale, n'y a-t-il pas du code permettant depuis "<demandeur><qualiteDemandeur>" de trouver "demandeur_qualiteDemandeur", ou l'inverse ? Plutôt que ces répétitions sources d'erreur et d'illisibilité ?

Illisibilité qui se retrouve derrière copiée dans cityweb_detail.html.

Discuté à l'instant lors de la pause déj: vu qu'on a déjà 2 connecteurs d'état civil, ne peut on avoir un seul qui expose la même API à Publik et qui transforme les demandes en fonction de la plateforme cible derrière. Comme on l'a fait dans le connecteur générique famille avec ses loaders spécifiques.

Discuté à l'instant lors de la pause déj: vu qu'on a déjà 2 connecteurs d'état civil, ne peut on avoir un seul qui expose la même API à Publik et qui transforme les demandes en fonction de la plateforme cible derrière. Comme on l'a fait dans le connecteur générique famille avec ses loaders spécifiques.

C'est la même discussion et conclusion que jeudi dernier.

class Father(Person):
    tagname = 'pere'
    pattern = 'parent1_'

Il n'y a rien dans les specs assurant que "parent1_" correspond au "père".

    @endpoint(perm='can_access')
    def channels(self, request):
        return {'data': CHANNELS}

Il n'y a rien dans la spec parlant de "channels".

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

[...]

Il n'y a rien dans les specs assurant que "parent1_" correspond au "père".

Pour éviter de faire un mapping bizarre comme je l'avais fait dans les anciens patch, je suis parti sur un data binding.
Du coup j'ai nommé les classes comme je le sentais.

tagname represente l'element xml lié à cet objet.
pattern me permet d'extraire les champs relatifs à cet objet du payload (ou une extraction de ce payload) reçu.

fichier xsd dans https://dev.entrouvert.org/issues/15219

Pour éviter de faire un mapping bizarre comme je l'avais fait dans les anciens patch, je suis parti sur un data binding.
Du coup j'ai nommé les classes comme je le sentais.

(je ne commente même pas)

class Father(Person):
    tagname = 'pere'
    pattern = 'parent1_'

Si je lis cet extrait correctement, et le code autour, le résultat sera un nœud "pere" pour les données présentes dans les clés …parent1_… du dictionnaire.

Rien ne dit dans la spec que "parent1" doit correspondre au "père". Je veux dire par là qu'une demande réalisée depuis w.c.s., elle pourra envoyer "concerned_parent1_firstnames": "Marie" et le code posera ça dans un nœud "pere", ce qui me semble une erreur.

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

Pour éviter de faire un mapping bizarre comme je l'avais fait dans les anciens patch, je suis parti sur un data binding.
Du coup j'ai nommé les classes comme je le sentais.

(je ne commente même pas)

[...]

Si je lis cet extrait correctement, et le code autour, le résultat sera un nœud "pere" pour les données présentes dans les clés …parent1_… du dictionnaire.

Rien ne dit dans la spec que "parent1" doit correspondre au "père". Je veux dire par là qu'une demande réalisée depuis w.c.s., elle pourra envoyer "concerned_parent1_firstnames": "Marie" et le code posera ça dans un nœud "pere", ce qui me semble une erreur.

Ok je comprends mieux, le parent1 et parent2 c'est dans l'optique de pouvoir utiliser une commune avec MDEL. Il y'a une documentation sur ce connecteur qui doit etre écrite.
C'est peut etre erreur, et il faudrait peut etre juste nommer les variables relatives aux parents de manière plus explicite e.g concerned_father_lastname ou concerned_mother_lastname

J'aurais nommé EVENTS_KIND en ACT_KIND car il ne s'agit pas d'un évenement mais d'un acte.

Quel est l'usage du paramètre without (que j'aurais appelé plutôt exclude)? Dans quels cas on va devoir exclure certains types de documents ou actes?

Dans la classe CivilStatusApplication il y a un print qui traine.

from passerelle.contrib.mdel.utils import zipdir

Surtout pas! Les connecteurs sont indépendants.

Il manque lxml dans tox.ini.

ORIGINGS = [...  <-- quelle langue ?

Les fichier zip produit serait dans media/cityweb/<slug>/<demand_id>/<demand_id>.zip. Pourquoi créer des répértoires par demande? Cityweb attend un zip ou un fichier xml?

No sé pour l'instant.

Mais euh, pour faire un connecteur, faut un peu savoir ça, non ?

Encore et toujours.

class Father(Person):
    tagname = 'pere'
    pattern = 'father_'

La spec ne parle pas de father_ et mother_ mais de parent1_ et parent2_. Je ne sais pas comment faire passer le message : il faut écrire du code. Ou dire qu'on se contrefiche d'une spec qu'on a écrit nous-mêmes. Ou discuter pour changer la spec.

Serghei Mihai a écrit :

Il manque lxml dans tox.ini.

Si lxml est une dépendance du paquet alors ça doit être pris en charge par setup.py et il n'est alors pas besoin de le répéter dans tox.ini, sinon il y a un problème.

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

No sé pour l'instant.

Mais euh, pour faire un connecteur, faut un peu savoir ça, non ?

Oui, mais c'est pas si grave en soi, vu que l'archive et le fichier xml sont quand meme fournis.

La spec ne parle pas de father_ et mother_ mais de parent1_ et parent2_. Je ne sais pas comment faire passer le message : il faut écrire du code. Ou dire qu'on se contrefiche d'une spec qu'on a écrit nous-mêmes. Ou discuter pour changer la spec.

Dans ta précédente intervention, j'ai cru comprendre que le fait d'utiliser parent n'avait pas trop de sens car non présent dans la spécification (xsd).
Sauf si par spéc tu entends https://dev.entrouvert.org/projects/passerelle/wiki/Connecteur_Etat_Civil.

Sauf si par spéc tu entends https://dev.entrouvert.org/projects/passerelle/wiki/Connecteur_Etat_Civil.

Oui bien sûr, la spécification pour nos connecteur état civil, dont tu es l'auteur, qui est discutée dans #17477.

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

Sauf si par spéc tu entends https://dev.entrouvert.org/projects/passerelle/wiki/Connecteur_Etat_Civil.

Oui bien sûr, la spécification pour nos connecteur état civil, dont tu es l'auteur, qui est discutée dans #17477.

Ok. Je vais changer la spec afin que les paramètres attendus dans le payload, quand il s'agit des parents soient father et mother pour la seule raison que citywbe et mdel attendent un xml avec les éléments père et mère.

Tu peux rebaser sur master et recoller le patch?

La fonction pretty sert uniquement à visualiser le XML généré? L'appeler plutôt __str__ ou __unicode__ ?

            if not attr:
                continue
            if isinstance(attr, (str, unicode)) and attr:

Je ne vois pas les situations où le "and attr" est utile.

class Certificate(SimpleType):
    tagname = 'natureEvenement'
    allowed_values = ('NAI', 'DEC', 'MAR', 'REC')

Ces valeurs dupliquent une information présente dans CERTIFICATE_TYPES. (pareil pour les autres énumérations)

Je ne pige pas le sens de l'objet "Demand"; en fait j'imagine qu'il gagne son sens avec l'ajout d'une récupération de statut et que le patch est incomplet. Le patch est incomplet ?

Je ne pige pas le sens de l'objet "Demand"; en fait j'imagine qu'il gagne son sens avec l'ajout d'une récupération de statut et que le patch est incomplet. Le patch est incomplet ?

Le patch est complet. Pas de récupération de statut avec cityweb. Je pense que c'est assez utile d'avoir quelques infos sur la demande dans passerelle, pratique en cas de pépin (expérience tirée de MDEL).

Je pense que c'est assez utile d'avoir quelques infos sur la demande dans passerelle, pratique en cas de pépin (expérience tirée de MDEL).

Tell me more. On a toutes les informations au niveau du file system : created_at (date du fichier), updated_at (pas pertinent jamais de modif), received_at (dans le fichier), resource (toujours la même), demand_id (dans le payload et le nom du fichier), kind (dans le fichier).

@endpoint...
def create(...):
    ...
    application = CivilStatusApplication(payload)
    application.save() # qui fasse le truc xml/zip
    return {'data': {'demand_id': application.get_demand_id()}}    

Plutôt que le jeu de piste actuel, où le endpoint crée demand_id mais retourne le résultat de demand.create(...) qui est en fait le demand_id qu'on avait déjà, et sans aucun rapport avec ce que la fonction zip() appelée dans le create() retourne (qui n'est pas utilisé).

Ok pour moi.

commit 3dbb768db7a10054501c2fccfa683da58c85e754
Author: Fred de la Conciergerie <fpeters@entrouvert.com>
Date:   Thu Sep 21 14:06:33 2017 +0200

    misc: declare missing python-dateutil dependency (#15883)