Produits Entr'ouvert » Passerelle

Il y a une nouvelle façon générique de faire les connecteurs depuis 1 jour ou deux ce serait bien que tous les nouveaux connecteurs s'y conforment, voir commit suivants de Fred:

22184d8 general: add a generic connector view (#11200)
72ae98d general: divide service_view template in common blocks (#11206)
78e998e general: make connectors work without appconfigs (#11201)
e644b3c general: add generic endpoint view (#11204)
b2be2c6 general: use a common template for _detail.html views (#11203)
0b58219 general: don't repeat management views in all connectors (#11199)

Je laisserai Fred donner le détail d'une migration vers ce nouveau canevas si il faut.

Oui merci. Mais j'avais commencé les dev en mi Mai. Je ferai les corrections nécessaires

description mise à jour = le travail se trouve publié là : http://git.entrouvert.org/passerelle.git/tree/?h=wip/10852

Tu peux faire signe quand la branche est mise à jour (vider le init.py, supprimer le forms.py, réduire le urls.py, etc.) ?

from utils import ElementFactory

Je suggérerais qu'on fasse from .utils import ElementFactory pour bien marquer qu'on va utiliser un module local au connecteur. Parce qu'une nouvelle manière de générer de l'XML dans Passerelle, c'est toujours bon à prendre.

NOW = datetime.datetime.utcnow().isoformat()

Renommer en NOW_AT_THE_TIME_THE_MODULE_WAS_LOADED ?

ZIP_DIR = os.path.join(settings.BASE_DIR, 'logitud')

Ça va faire un chemin sous /usr/, il me semble, pas le genre d'endroit où on peut écrire. Il faut utiliser l'API de gestion des fichiers de Django, https://docs.djangoproject.com/en/dev/ref/files/storage/

class LogitudBase(object):
...
class Common(LogitudBase):
...
class Message(Common):
...
class Description(Common):
...

La classe "Common" me semble juste une classe intermédiaire inutile, pourquoi ne pas tout faire dériver de LogitudBase ?

(et il y a de la réindentation sans rapport dans logitud: add message.xml and -ent-xml files)

"logitud: make ElementFactory return itself when append/extend are called"

Le commit qui introduit ElementFactory apparait un peu plus tôt, il pourraient être réunis.

"logitud: define title as filename in AttachedFile object"

Pareil, ça pourrait être réuni avec le commit introduisant AttachedFile.

xmlns =\
'http://finances.gouv.fr/dgme/gf/composants/teledemarchexml/donnee/metier'

Pour la lisibilité on s'autorise parfois des lignes dépassant les 80 caractères.

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

Tu peux faire signe quand la branche est mise à jour (vider le init.py, supprimer le forms.py, réduire le urls.py, etc.) ?

from utils import ElementFactory

Je suggérerais qu'on fasse from .utils import ElementFactory pour bien marquer qu'on va utiliser un module local au connecteur. Parce qu'une nouvelle manière de générer de l'XML dans Passerelle, c'est toujours bon à prendre.

NOW = datetime.datetime.utcnow().isoformat()

Renommer en NOW_AT_THE_TIME_THE_MODULE_WAS_LOADED ?

ZIP_DIR = os.path.join(settings.BASE_DIR, 'logitud')

Ça va faire un chemin sous /usr/, il me semble, pas le genre d'endroit où on peut écrire. Il faut utiliser l'API de gestion des fichiers de Django, https://docs.djangoproject.com/en/dev/ref/files/storage/

class LogitudBase(object):
...
class Common(LogitudBase):
...
class Message(Common):
...
class Description(Common):
...

La classe "Common" me semble juste une classe intermédiaire inutile, pourquoi ne pas tout faire dériver de LogitudBase ?

(et il y a de la réindentation sans rapport dans logitud: add message.xml and -ent-xml files)

"logitud: make ElementFactory return itself when append/extend are called"

Le commit qui introduit ElementFactory apparait un peu plus tôt, il pourraient être réunis.

"logitud: define title as filename in AttachedFile object"

Pareil, ça pourrait être réuni avec le commit introduisant AttachedFile.

xmlns =\
'http://finances.gouv.fr/dgme/gf/composants/teledemarchexml/donnee/metier'

Pour la lisibilité on s'autorise parfois des lignes dépassant les 80 caractères.

Je prends en compte des remarques. Il y'a une discussion en cours dans ce ticket #11176

Je prends en compte des remarques. Il y'a une discussion en cours dans ce ticket #11176

Il y a deux tickets techniques pour parler des mêmes patchs ? Je propose d'en fermer un des deux.

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

Je prends en compte des remarques. Il y'a une discussion en cours dans ce ticket #11176

Il y a deux tickets techniques pour parler des mêmes patchs ? Je propose d'en fermer un des deux.

• Demande d'inscriptions sur liste électorale
• Demande d'acte d'état civil
• Recensement obligatoire

Les patchs dont on parle sont plutot relatifs au #11176 (Inscription sur Liste Electorale)

De l'intérieur c'est peut-être limpide mais de l'extérieur, quand même, on en est loin :

Ce ticket traite du développement général du connecteur Logitud (MDEL):

• Demande d'inscriptions sur liste électorale

et deux lignes plus loin :

Les patchs dont on parle sont plutot relatifs au #11176 (Inscription sur Liste Electorale)

Et pour bien rigoler, une fois que tout aura été relu, il y aura #11305 qui renommera tout.

Bref, à défaut de faire un seul ticket, ce qui correspondra à une seule branche, (ce qui est ce que tu fais malgré tout); je suggérerais de supprimer le #11305 et de l'inclure dans ce ticket, et de préciser ici qu'il s'agit de fondations. (sauf si #11305 n'est pas pertinent et alors il faut le rejeter).

Et pour ces fondations de tenir compte des changements récents dans Passerelle (vider le init.py, supprimer le forms.py, réduire le urls.py, etc.).

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

De l'intérieur c'est peut-être limpide mais de l'extérieur, quand même, on en est loin :

Ce ticket traite du développement général du connecteur Logitud (MDEL):

• Demande d'inscriptions sur liste électorale

et deux lignes plus loin :

Les patchs dont on parle sont plutot relatifs au #11176 (Inscription sur Liste Electorale)

Et pour bien rigoler, une fois que tout aura été relu, il y aura #11305 qui renommera tout.

Bref, à défaut de faire un seul ticket, ce qui correspondra à une seule branche, (ce qui est ce que tu fais malgré tout); je suggérerais de supprimer le #11305 et de l'inclure dans ce ticket, et de préciser ici qu'il s'agit de fondations. (sauf si #11305 n'est pas pertinent et alors il faut le rejeter).

Pour faire bref, c'est un connecteur à 3 fonctions :

• Demande d'inscriptions sur liste électorale (développement en cours)
• Demande d'acte d'état civil
• Recensement obligatoire

Et pour ces fondations de tenir compte des changements récents dans Passerelle (vider le init.py, supprimer le forms.py, réduire le urls.py, etc.).

Il y'a un ticket que j'ai ouvert #11418

Il y'a un ticket que j'ai ouvert #11418

Et donc pour la branche ce n'est pas trois tickets à reviewer mais quatre. Je pense qu'on peut avoir des tickets pour se rappeler qu'il faut faire ceci-cela, mais que la relecture, elle est bien plus facile si elle se fait une fois que les différents morceaux sont traités et qu'on peut lire une branche dans son intégralité, plutôt que devoir recomposer le puzzle.

Josué, je suis d'accord avec Fred, tant qu'un développement n'est même pas commité ça ne sert à rien de multiplier les tickets et les commits autant traiter tout d'un coup dans un seul ticket et un seul commit, idem le #11418 de toute façon on ne te laissera pas pousser une version qui ne soit pas dans la nouvelle norme, donc autant suivre tout ici. Des fois le plus simple c'est de remerger tous tes patchs en un seul et éventuellement d'en refaire un découpage en patch avec git gui (enfin moi je fais comme ça des fois quand l'historique commence à ressembler à n'importe quoi), mais bon là à mon avis un seul commit suffirait.

Ok. Mais l'on m'a tellement dit que mes patches était trop long et qu'il fallait les séparer. Et que pour pouvoir suivre mes développement, il fallait que je fasse des tickets.
Si je comprends bien, pour ce genre de dev, le mieux c'est un seul ticket avec plusieurs patches s'il le faut ?
Je vais cloturer les autres tickets et continuer sur celui-ci.

Si ton patch aborde des sujets qui n'ont aucun rapport, genre au milieu d'un patch pour une feature X tu corriges un bug Y; alors oui fais deux tickets et deux patchs. Mais dans le cas d'une nouveau connecteur, on n'a pas envie de lire le cheminement de ton développement, on veut lire le produit fini, c'est bien trop compliqué de recombiner les patchs dans sa tête.

Il n'y a pas de règle absolue qu'on puisse suivre, c'est du bon sens.