Produits Entr'ouvert » Passerelle

C'est à dire ? Si tu as un plan, n'hésite pas à le décrire.

Benjamin Dauvergne a écrit :

C'est à dire ? Si tu as un plan, n'hésite pas à le décrire.

L'idée c'est:
1. Arriver à avoir une api similaire à ce qui est en train d'etre fait pour l'état civil.
2. Changer le code de transformation de formdata wcs en xml qui marche grace à un système de mapping pas très élégant pour arriver à quelque chose d'un peu déclaratif comme ce qui a été fait pour cityweb (ou mieux). De plus ça permet d'avoir une validation des données à un seul endroit, ce qui n'est pas le cas pour l'instant.

Comme l'a dit Thomas un schéma XML ne donne qu'une vague idée des données (on a pas le format exact par exemple, souvent on a juste "string" ou "integer" sans avoir le référentiel associé). Donc c'est un peu court.

Benjamin Dauvergne a écrit :

Comme l'a dit Thomas un schéma XML ne donne qu'une vague idée des données (on a pas le format exact par exemple, souvent on a juste "string" ou "integer" sans avoir le référentiel associé). Donc c'est un peu court.

Yep je comprends. L'autre argument est que si jamais il y'a de nouvelles demarches à ajouter à ce connecteur, on risque de continuer sur de mauvaises bases, quoique l'on peut aussi le faire à ce moment là.

Le mercredi 04 avril 2018 à 10:42 +0200, redmine@entrouvert.com a écrit :

Yep je comprends. L'autre argument est que si jamais il y'a de nouvelles demarches à ajouter à ce connecteur, on risque de continuer sur de mauvaises bases, quoique l'on peut aussi le faire à ce moment là.

Le principe même d'un développement générique, c'est précisément d'anticiper les usages futurs et de ne pas attendre "ce moment là" pour faire les choses correctement. C'est plus difficile, c'est plus long, mais c'est aussi plus rentable à terme.

Pierre Cros a écrit :

Le mercredi 04 avril 2018 à 10:42 +0200, redmine@entrouvert.com a écrit :

Yep je comprends. L'autre argument est que si jamais il y'a de nouvelles demarches à ajouter à ce connecteur, on risque de continuer sur de mauvaises bases, quoique l'on peut aussi le faire à ce moment là.

Le principe même d'un développement générique, c'est précisément d'anticiper les usages futurs et de ne pas attendre "ce moment là" pour faire les choses correctement. C'est plus difficile, c'est plus long, mais c'est aussi plus rentable à terme.

C'est tout à fait ce qu'il voulait, donc je pense que tu me réponds. Je signale juste que pour moi on a pas encore les informations nécessaires pour avancer sauf à dire qu'on a l'expérience nécessaire sur toutes les démarches MDEL pour pouvoir en faire un truc générique.

Pour aller dans le détail en plus du XSD qui nous donne la structure il nous faudrait les informations nécessaire pour l'annoter avec un typage plus avancé sinon autant continuer sur notre fonctionnement actuel i.e. on décrit les champs dans un dico de description, en fait c'est quasiment la même chose que de partir d'un XSD (même en partang d'un XSD des fois il y a des bugs dedans si en fait personne ne s'en sert vraiment pour générer des documents ou les valider).

De mon point de vue, on ne peut pas attendre d'avoir été confronté à tous les usages existant avant d'insuffler de la généricité.

Nous avons, dans plusieurs villes, des formulaires pour toutes les demandes d'actes, le recensement et l'inscription sur les listes électorales. Cela ne suffit pas pour faire le typage dont tu parles ?

Pierre Cros a écrit :

De mon point de vue, on ne peut pas attendre d'avoir été confronté à tous les usages existant avant d'insuffler de la généricité.

• le coté w.c.s, et on a un truc commencé via le ticket #16768 "Faire une api commune pour les connecteurs d'état civil" c'est bien sauf que MDEL c'est aussi les listes électorales, le changement d'adresse et je ne sais foutre pas combien d'autres démarches qu'ils pourraient imaginer à l'avenir. On peut continuer sur cette voie sauf que ce n'est pas du tout spécifique à MDEL (ActesWeb utilise son propre format de WS), on a pas un match complet entre une interface coté w.c.s. et une implémentation logicielle de l'autre (MDEL fait tout ça mais ActesWeb que l'état-civil, et un autre logiciel fera les listes électorales, etc...); si on en fait beaucoup sur ce format on aura pas toujours correspondance, mais ce n'est pas très grave.
• la généricité coté MDEL: avoir un connecteur MDEL unique (ayant devant l'interface générique du point précédent) pour tous les logiciels compatibles MDEL et là il me semble qu'on manque cruellement d'expérience et que le XSD n'est qu'une piètre information par rapport à la spécification qu'il faudrait; ces logiciels ont été écrit en se raccordant à MDEL et en testant la chose pas en lisant bêtement le XSD et les docs associés, si MDEL diffère de la spec, ils se sont adaptés, il faut qu'on reproduise le comportement de MDEL exactement pas juste la spéc. Donc avant de se dire hop j'ai un XSD je vais générer le connecteur pouf-pouf il faut avoir expérimenter avec 2/3 logiciels le connecteur existant (auquel on peut très bien greffer la nouvelle interface coté w.c.s. ça pas de souci) sur toutes les démarches état-civil et listes électorales (la démarche changement d'adresse c'est un truc informe qu'on ne peut connecter à rien, juste envoyer des mails aux services je pense).

Nous avons, dans plusieurs villes, des formulaires pour toutes les demandes d'actes, le recensement et l'inscription sur les listes électorales. Cela ne suffit pas pour faire le typage dont tu parles ?

Je pense que tu penses à la première version de la généricité alors que ce ticket concerne surtout la seconde (spécifique à MDEL), car introduit dans sa description par "Vu qu'on a maintenant les .xsd spécifiant les différentes demarches MDEL.".