[GRAVE] JSON->XML ! AJOUT D'UNE LIBRAIRIE

[FlorentMouysset]

@JackDanny @NawalOuldamer @medi24 @smailGithub @RaphaelFOURQUET

Au terme de tests : je ne peux plus garantir l'ordre des éléments XML dans les "questions". L'ordre des questions est (peut être) respecté (cf @JackDanny @smailGithub #30) mais à l'intérieur on ne peut plus !

Que faire ? Redescendre dans la librairie ou changer de librairie ou rien ?

Détail :

• JSONArray utilise en interne une ArrayList = garanti l'ordre du JSON
• JSONObject utilise une map qui ne garanti plus l'ordre du Json :-1: !!

[FlorentMouysset]

Le problème est confirmé par le doc ! RTFM je dois + ! Que faire donc ? Ya il quelqu'un ??

[RaphaelFOURQUET]

Il faut se demander si l'ordre des balises est important en xml ou non ? car l'arborescence sera respectée de toute façon, le seul problème que cela pose c'est qu'il faudra chercher les attributs dans la liste de tous les fils et non pas forcément le suivant. D'après ce que j'ai fait en l'utilisant dans l'autre sens, l'ordre des questions et des answers sera bon car dans une liste mais les answers de la queston pourraient être présents avant son questionText par exemple, est-ce grave? Si oui il faudrait retrouver parmi les fils lequel placer en premier à chaque fois( de la même façon que l'on cherche l'attribut ), et donc définir la structure de chaque type de question comme on devait le faire avec Jackson.

PS : dans l'autre sens XML->Json pas de soucis car j'utilise une LinkedHashMap qui a l'air de garantir l'ordre.

[FlorentMouysset]

Trouver un attribut n'est pas difficile (je l'ai déjà fait faut être exhaustif). Le sujet est relativement vague :"[...] créer un fichier au format Moodle XML à partir d’un fichier fourni au format JSON (dont la structure et le contenu correspondent à un quizz Moodle)" Mais comme il n'y a pas de "schéma" moodle spécifique à respecter... Je peux respecter l'ordre de l'exemple fournit mais cet exemple ne respecte pas(??) l'ordre indiqué sur http://docs.moodle.org/22/en/Moodle_XML_format Le souci s'est de ne pas oublier d'éléments c'est pourquoi je souhaitais parcourir une collection et non être calqué sur l'exemple. Du coup je vais calquer l'exemple puis je compterais les éléments pour ne pas faire d’oublis, ajouter ce qui manque si besoin. Donc dans le pire des cas les éléments serons dans l'ordre de l'exemple (donné) et non dans l'ordre du fichier en entrée mais il restera complet.

[FlorentMouysset]

Du coup je continue ... ?

[RaphaelFOURQUET]

Quand tu parles de l'exemple donné c'est exemple-moodle.xml sur notre moodle ups ? Je n'avais pas remarqué qu'il ne respectait pas l'ordre de http://docs.moodle.org/22/en/Moodle_XML_format, mais oui continue en te basant sur l'exemple il a l'air d'y avoir plus de types de questions différentes.

edit : il y a également des types de questions presentes sur la doc et pas dans l'exemple, (type = essay par exemple), il faut donc se baser sur les deux je pense.

Par contre du coup quand tu parles de compter et vérifier, tu corriges le doc de départ s'il est faux( ajouter ce qui manque si besoin), je ne le fais pas dans XML to Json, si un element est manquant à la base il le sera dans le resultat final, pas de "corrections" étant donné que je ne calque aucun exemple, traduction pure. Vaut-il mieux corriger si balise manquante? ou lever une exception et indiquer que le doc en entrée n'est pas conforme au schéma MoodleXML ?

[FlorentMouysset]

Ok c'est bon j'ai pris les "très gros moyens" : j'ai modifier les sources de la librairie ! Mais je ne sais pas si c'est vraiment bien. Je respecte la licence de la librairie, par contre : On ne peut plus passer par la gestion de dépendance Maven pour cette librairie. Il faut ajouter le dossier "org.json-chargebee-1.0-sources" aux sources en éditant le builpath. Sinon le reste du fonctionnement ( @JackDanny @smailGithub ) n'est pas affecté.

Détail : il suffit de rajouter 6 lettres sur une ligne ! "HashMap" -> "LinkedHashMap" dans les sources (merci @RaphaelFOURQUET pour la piste) ! La solution n'a pas encore été testé de manière exhaustive. Mais semble solide et viable. Je continue le dev (normalement mon prochain commit clos ce problème)

[RaphaelFOURQUET]

Donc chacun d'entre nous devra éditer le buildpath? et pour mon travail qui utilise la librairie originelle sans problème, on laisse la dépendance maven pour ça où on utilise également ta modif, ça ne doit pas changer ce que j'ai fait normalement? Je testerais si ce que j'ai fait marche encore après ton commit

[RaphaelFOURQUET]

Très mauvaise idée de close cette issue directement,comme je l'ai dit plus haut il reste des problèmes à régler : mon travail utilise encore la librairie originelle donc la dépendance pom comme je l'ai dit, de plus il faut s'assurer que tlm ait modifié le buildpath pour pouvoir faire tourner ton code. Donc je propose de close seulement quand tout le monde aura ajouté ta librairie à son buildpath pour que personne n'oublie de le faire.

Et comment dois-je modifier mes imports pour utiliser ta librairie modifiée plutot que celle de base? remplacer le import net.sf.json.JSONObject; par import org.json.JSONObject; suffit ?

Ps : je n'ai pas besoin de la librairie modifiée mais puisque tu l'as enlevé du pom je devrais l'utiliser je pense.

[smailGithub]

@FlorentMouysset @RaphaelFOURQUET
Bonjour camarade, Je suis un peu perdu dans cette issue? 1) je ne comprend pas si #30 est résolue ou pas? 2)Qu'attendez vous exactement de #31 ? 3) Je vois des librairies,doit on les ajouter à la main , ou juste faire un pull?

Merci

[RaphaelFOURQUET]

30 resolu par la modification de la librairie par florent, mais il faut maintenant que tout le monde ajoute manuellement la librairie après un pull :

Il faut ajouter le dossier "org.json-chargebee-1.0-sources" aux sources en éditant le builpath, comme @FlorentMouysset l'a dit.

projet -> properties-> Java build path-> source ->add Folder ->org.json-chargebee-1.0-sources devrait marcher

[smailGithub]

Si je m'en occupe, et que je fait un push? cette issue pourra être closed?

[RaphaelFOURQUET]

Le java build path est propre à ton environnement eclipse , il ne peut etre push je pense que tlm doit le faire pour soi, à confirmer. De plus il reste toujours mon problème d'import à régler (cf plus haut lorsque j'ai réouvert l'issue).

[smailGithub]

Yes @RaphaelFOURQUET ca marche bien ! Dois je crée une issue ou je donnerai les instructions à suivre pour régler ce problème?

[RaphaelFOURQUET]

Pas la peine les étapes sont déjà décrites ici, on va juste attendre que tlm confirme ici avoir modifié le buildpath pour close.

• toujours mon problème d'import à résoudre aussi.

[smailGithub]

Ok @RaphaelFOURQUET

[RaphaelFOURQUET]

Import résolu, j'utilise bien maintenant la librairie modifiée, par contre cela m'oblige à gérer des exceptions en plus lors du JSONObject.put.

[smailGithub]

@RaphaelFOURQUET est ce que ce problème est propre à ton projet en locale ?

[FlorentMouysset]

STOPPP !! Autant pour moi. Mais import net.sf.json.JSONObject; import org.json.JSONObject; Sont 2 librairie différentes !

[FlorentMouysset]

Normalement PERSONNE n'a à modifier des imports ! Je l'ai fait expré pour pas tout modifier. Il faut "juste" ajouter le code source de la librairie dans le builPath Je rappel la librairie impacté est juste la "org.json" le reste de bouge pas.

Le problème est qu'il ya 2 librairie JSON donc.

[RaphaelFOURQUET]

Oui on ajoute juste MAIS mon code utilisait la librairie que tu as modifié, alors soit on la laisse dans le pom et je l'utilise comme avant (mais on aura deux librairies pour le JSon) Soit je modifie mes imports pour utiliser la tienne et on vire l'originelle du pom (ce que tu as fait il me semble). et import net.sf.json.JSONObject; import org.json.JSONObject; sont les même librairies non? juste que tu as modifié la seconde pour intégrer les LinkedHashMap. Car j'ai modifié mes imports pour prendre en compte la second et ca ne change quasiment rien.

Donc dis moi si j'ai mal compris ou pas, mais si je garde mon ancienne librairie il faut la remettre dans le pom.

[FlorentMouysset]

Ce qui est sure c'est que org.json doit virer du pom : normalement le l'ai commentée dans le pom. Et que tu ne devrais pas a modifier tes importe après avoir ajouté la librairie dans le build path. -> As-tu bien indiqué la racine "org.json-chargebee-1.0-sources" comme "new folder sources" ? net.sf.json je sais rien dessus.

[RaphaelFOURQUET]

Ok net.sf.json est toujours dans le pom ce n'est pas celle que tu as modifié apparement même si très semblable. Du coup on se retrouve quand même à utiliser deux librairies Json différentes pour xmlToJson et JsonToXML. Je pensais que tu avais repris celle de nawal.

Car mon code marche très bien quelque soit l'import que j'utilise je voulais juste rester cohérent dans le choix.

[FlorentMouysset]

Je ne l'ai pas trop regardé mais @NawalOuldamer disé que net.sf.json était basé sur Jackson (on en vois encore des trace dans le maven dependencies). net.sf.json est encore utilisé par quelqu'un ?

[RaphaelFOURQUET]

Bah du coup oui moi j'ai repassé mon code en net.sf.json car cela me dispense de quelques gestions d'exceptions par rapport au org. Mais les deux ont les mêmes méthodes qui font la même chose sinon car mon code donne les mêmes résultats avec les 2 imports aux exceptions près ( pour mon code ). On l'utilise aussi dans JsonGen de nawal mais cette classe est finalement inutilisée, on va sans doute pouvoir la supprimer.

[RaphaelFOURQUET]

@NawalOuldamer @JackDanny @medi24 Vous n'avez pas encore répondu à cette issue, merci de nous indiquer si vous avez réussi à intégrer la librairie modifiée qui n'est pas dans le pom pour que l'on puisse close cette issue : Rappel de la procédure : projet -> properties-> Java build path-> source ->add Folder ->org.json-chargebee-1.0-sources .

[medi24]

Oui ,j'ai réussi à l'integrer.

[FlorentMouysset]

50 fait une synthèse du pb et le reprend.

En effet le sujet du début à beaucoup dévié.