On Fri, 09 Dec 2011 14:33:53 +0100 desbois <desbois@codelutin.com> wrote:
Salut,
J'ai continué les TU sur nuiton-csv, et notamment tester le ModelBuilder. Mais j'ai un doute de son utilité.
Il faut surtout ce concentrer sur tester des choses interessante je crois... cette api sert bien à importerexporter en csv, donc je vois pas trop l'intérêt de tester la création d'un modèle csv :( Par contre tester que la mécanique d'Importexport fonctionne c'est plus important.
En gardant l'idée de l'api, j'ai fais une implem un peu plus pousser avec une methode buildImportModel qui te renvoie directement un ImportModel avec les différentes colonnes construites.
Finalement il serait plus simple que le ModelBuilder implémente les deux interfaces ImportModel et ExportModel, on pourrait le renommer en CsvModel. Pour les besoins spécifiques rien n'empêchera l'héritage. Ainsi pushCsvHeaderNames sera vide par défaut et étendu au besoin (d'ailleurs je la renommerais bien en onReadHeaders pour montrer son côté callback). Même chose pour le newInstance, en passant la classe au constructeur du modèle, on peut proposer une implem par défaut avec un myClass.newInstance. Libre à l'utilisateur de surcharger s'il veut un comportement plus pousser (utiliser sa propre factory). Une autre idée serait de proposer des contrats pour avoir un callback sur les headers et une factory pour l'instanciation.
Je reviens aussi sur les interfaces ImportableColumn et ExportableColumn que je trouve inutiles. Il faut juste permettre le !mandatory & !ignored dans la classe Column.
Pour l'Import je rajouterais bien aussi des méthodes qui l’exécute directement sans avoir besoin d'instance d'Import. Par exemple :
public static <E> List<E> getResultAsList(ImportModel<E> model, Reader reader) { Import<E> instance = Import.newImport(model, reader); try { List<E> result = new ArrayList<E>(); for (E row : instance) { result.add(row); } return result; } finally { instance.close(); } }
En pratique on pourrait avoir :
CsvModel<Row> model = CsvModel.newModel(';', Row.class); model.addMandatoryColumn("TITLE", "title"); model.addMandatoryColumn("DATE", "date", new Common.DateValue("yyyy-MM-dd")); model.addMandatoryColumn("NUMBER", "number", Common.INTEGER);
Je suis contre cette approche car un modèle ne devrait JAMAIS être responsable de sa construction. Pour moi (on en discuté hier avec Brendan) y'a un gros pb dans cette api, les choses sont mal nommée et des concepts de builder/model et factories sont bien mélangées. On doit revoir ça.
List<Row> results = Import.getResultAsList(model, reader);
Qu'en pensez-vous ?
je vais maintenant regarder l'Export voir si ça se goupille bien. Je pense qu'on peut avoir une api bien sympa en tout cas, mais ya encore pas mal de chose à voir pour simplifier/fignoler.
Pour le moment faut qu'on arrive à trouver une meilleure manière de faire à plusieurs Donc je ne pense pas que ça soit une bonne qu'une personne seule fasse les modifs que ça soit moi ou toi ;) On pourrait s'organiser une petite session de travail autour de ça. Je propose (Julien me souffle ça dans l'oreille) qu'on peut mettre ça à l'ordre d'une prochaine réunion dev ;) Mais de grâce pas de despotisme à vouloir tout chambouler : je me sers de l'api sur echobase, brendant devrait rapidemment s'en servir aussi sur wao donc on change pas tout :) -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com