Export xml

[lucas-v]

Ready for merge.

I had to merge the code in Normalize manually.

[jpimbert]

Il reste quelques points à traiter avant que je puisse accepter ce Pull Request :

• ajouter l'export du XML au Handler BeforeSave ajouté au projet lors de sa création
• refaire un export/normalize de tous les modules avant le merge avec upstream/master. J'avais pris la peine de tout re-normaliser et ton pull-request me propose des fichiers dé-normalisés (vtkConfiguration et vtkConfigurationManagers par exemple)
• je ne peux pas vérifier le merge avec ces très très très très énervants fichiers qui sont considérés comme totalement ré-écrits (FileSystemUtilities par exemple). N'y a-t-il pas un problème de codage de fin de ligne ? Comment as-tu paramétré le traitement des fins de ligne à l'initialisation de Git ? Ou alors c'est un problème de tabulations/espaces ?

[jpimbert]

Le dernier commit est inquiétant :

• suppression de l'export du XML ?
• il y a des différences de Normalisation alors que le code est maintenant réputé normalisé
• As tu installé le dernier VBAToolKit pour pouvoir utiliser la normalisation ?

[lucas-v]

• Je ne sais pas pourquoi l'export XML a été supprimé. C'est peut-être moi pour des tests mais ça m'inquiète moi-même.
• Les différences de normalisation sont selon ce qui est listé dans l'add-in ("Count" , "Number"). Celui qui nous agacera encore est "fileExists" puisqu'il n'est pas dans l'add-in.
• Oui.

[lucas-v]

Pour les commentaires pré-acceptation de la pull request :

• OK
• OK
• Vous avez raison de penser au codage de fin de lignes. J'ai réglé Git pour committer avec des fins de ligne Unix standard, par checkouter avec des fins de ligne Windows. C'est vrai qu'on n'avait pas pensé à ça et que ce n'est pas dans le wiki. Comment est réglé votre Git à vous ?

[jpimbert]

Fins de ligne : L'information est dans le Wiki (VBAToolKit SetUp) - de fait nous n'avons pas les mêmes réglages et cela peut expliquer les problèmes que nous avons depuis le début.

S'il y a encore des problèmes de normalisation il faut les traiter au fur et à mesure (FileExists, et j'ai vu un M aussi). Et je ne comprends pas ton explication concernant Number et Count. Chez moi c'est normalisé (vtkConfogurationManager) et chez toi non.

[lucas-v]

• Ok pour les fins de ligne, je n'avais pas vu ça quand j'ai installé mon Git.
• Je suis d'accord pour les problèmes de normalisation, c'est à faire au fur et à mesure. J'ai rajouté tout ça. Je ne sais pas pourquoi vtkConfigurationManager n'était pas normalisé. C'est corrigé. Pas grave pour l'explication.
• Je n'avais pas mis l'export de XML dans le handler et je l'avais mis dans le wiki. Maintenant c'est dans le handler et dans le handler.

[jpimbert]

Une idée géniale de dernière minute … Il me semble que ton Export ne se base plus maintenant que sur la feuille Excel vtkConfigurations. L'export ne serait alors à faire que si cette feuille a été modifiée depuis la dernière sauvegarde (il faudrait ajouter une méthode à vtkConfigurationManager).

[lucas-v]

En effet l'export ne se base que sur la feuille vtkConfigurations. Je ne pense pas que ça vaille le coup de passer du temps à implémenter ça :

• Cette feuille est vouée à disparaitre. Dès le prochain sprint, l'export sera basé sur le configuration manager créé à partir des infos contenues dans le xml, plus sur la feuille vtkConfigurations.
• Exporter à chaque fois n'est pas gênant vu que s'il n'y aucun changement entre 2 versions du fichier xml, git ne le committera pas. J'attends votre retour sur ces objections.

[jpimbert]

OK pour ne pas implémenter mon idée géniale. Mais ça me chagrine tout de même de faire un truc pas fini. Dans la prochaine version, l'export lui-même disparaîtra (inutile d'exporter en XML se qui se trouve déjà en XML) ou au moins prendra une forme différente.

[lucas-v]

Pour tout vous dire, je vois les choses d'un autre angle (peut-être plus KISS) : si on peut s'épargner du travail déjà fait par Git, c'est plus une bonne idée qu'une mauvaise. Dans cet ordre d'idée, je me suis rendu compte que la normalisation des fichiers rendait quasi inutile l'option onlyModified : on a implémenté cette option pour limiter l'énervement dû à la casse qui change tout le temps, mais si tout est normalisé, les fichiers modifiés ne changent pas, même s'ils sont réexportés. La form de create project est détectée comme modifiée, mais pas les autres modules. Mais comme vous dites, l'export sera sous une forme différente assez vite.

[jpimbert]

Il n'y a plus les gros écarts sur la totalité des fichiers : Super !!

Mais :

• dans l'export dans l'auto-save, il est fait appel à VBAToolKit_DEV. pourquoi pas VBAToolKit ?
• l'obtention du chemin pour le projet pourrait utiliser vtkPathOfCurrentProject(wb) et les fonctions de vtkProject
• count n'est pas normalisé dans plusieurs fichiers (ImportExportUtilitiesTester, ConfigurationTester, ModuleTester, NormalizeTester, TestUtilitiesTester)
• il apparaît deux nouveaux tokens à normaliser "actual" et "Tests"

[lucas-v]

On s'en approche !

• Pour l'export XML ? Si c'est le cas, c'est juste qu'il n'est pas encore dans l'ad-in (le master)
• OK
• Il y a un bug dans l'analyseur syntaxique avec la virgule. Les occurences de count qui ne sont pas normalisées sont celles entre un point et une virgule. Je le corrigerai (sur une branche séparée ?)
• OK. Si on update souvent cette liste, autant la mettre dans un fichier texte ! Qu'en pensez-vous ?

[jpimbert]

• C'est l'appel dans ThisWorkbook qui ne va pas vers l'add-in