[nuiton-csv] ModelBuilder
Salut, J'ai continué les TU sur nuiton-csv, et notamment tester le ModelBuilder. Mais j'ai un doute de son utilité. 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); 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. --------------8<----------------8<--------------8<----------------- Exemple plus compliqué comme dans WAO : CSV: --- TITLE;01/2010;02/2010;03/2010 "Row1";1;2;3 "Row2";5;0;1 "Row3";4;1;0 Import: --- CsvModel<Row> builder = CsvModel.newModel(';', Row.class); builder.addMandatoryColumn("TITLE", "title"); builder.setHeadersCallback(new CsvModel.HeadersCallback() { @Override public void onReadHeaders(List<String> headerNames) { List<String> dynamicHeaders = headerNames.subList(1, headerNames.size()); for (String header : dynamicHeaders) { // Format header to have Date value Date month; try { month = DateUtils.parseDate(header, "MM/yyyy"); } catch (ParseException e) { throw new ImportRuntimeException("Parsing error of dynamic header " + header, e); } // Add the dynamic column using Row specified setter builder.addMandatoryColumn( header, Common.INTEGER, Row.getMonthValueSetter(month) ); } } }); List<Row> results = Import.getResultAsList(model, reader); Row : --- public class Row { private String title; private SortedMap<Date, Integer> monthValues; public Row() { this.monthValues = new TreeMap<Date, Integer>(); } public String getTitle() { return title; } public void setTitle(String title) { this.title = title; } public void addMonth(Date month, Integer value) { monthValues.put(month, value); } public Map<Date, Integer> getMonthValues() { return monthValues; } public static ValueSetter<Row, Integer> getMonthValueSetter(final Date month) { return new ValueSetter<Row, Integer>() { @Override public void set(Row object, Integer value) throws Exception { object.addMonth(month, value); } }; } }
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
On Fri, 9 Dec 2011 14:56:25 +0100, Tony Chemit <chemit@codelutin.com> wrote:
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.
Ben sur l'import, t'as CsvReader derrière donc a priori c'est déjà bon, ici on doit bien tester l'api qui a été créé, dont le ModelBuilder. De plus cela permet d'avoir des cas pratiques d'implémentation pour voir si l'api est judicieuse.
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.
Je suis d'accord
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 ;)
Vi en effet, je ne commite pas mes modifs à cause de ca. <troll du vendredi>Et tiens git aurait été cool pour ca !</troll du vendredi>
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 ;)
Ok ca me va. Je peux être dispo demain si ca te dit :D Qui serait intéressé ?
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 :)
Bien evidemment je sais que vous l'utilisez ;) j'ai jamais fais par de despotisme, je te prierais d'éviter ce genre de propos déplacé.
On Fri, 09 Dec 2011 15:30:15 +0100, desbois <desbois@codelutin.com> wrote:
On Fri, 9 Dec 2011 14:56:25 +0100, Tony Chemit <chemit@codelutin.com> wrote:
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.
Ben sur l'import, t'as CsvReader derrière donc a priori c'est déjà bon, ici on doit bien tester l'api qui a été créé, dont le ModelBuilder. De plus cela permet d'avoir des cas pratiques d'implémentation pour voir si l'api est judicieuse.
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.
Je suis d'accord
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 ;)
Vi en effet, je ne commite pas mes modifs à cause de ca. <troll du vendredi>Et tiens git aurait été cool pour ca !</troll du vendredi>
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 ;)
Ok ca me va. Je peux être dispo demain si ca te dit :D Qui serait intéressé ?
Oups, dans ma tête j'avais compris coding party. My bad.
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 :)
Bien evidemment je sais que vous l'utilisez ;) j'ai jamais fais par de despotisme, je te prierais d'éviter ce genre de propos déplacé.
_______________________________________________ Nuiton-utils-devel mailing list Nuiton-utils-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/nuiton-utils-devel
On Fri, 09 Dec 2011 15:30:15 +0100 desbois <desbois@codelutin.com> wrote:
On Fri, 9 Dec 2011 14:56:25 +0100, Tony Chemit <chemit@codelutin.com> wrote:
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.
Ben sur l'import, t'as CsvReader derrière donc a priori c'est déjà bon, ici on doit bien tester l'api qui a été créé, dont le ModelBuilder. De plus cela permet d'avoir des cas pratiques d'implémentation pour voir si l'api est judicieuse.
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.
Je suis d'accord
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 ;)
Vi en effet, je ne commite pas mes modifs à cause de ca. <troll du vendredi>Et tiens git aurait été cool pour ca !</troll du vendredi>
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 ;)
Ok ca me va. Je peux être dispo demain si ca te dit :D Qui serait intéressé ?
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 :)
Bien evidemment je sais que vous l'utilisez ;) j'ai jamais fais par de despotisme, je te prierais d'éviter ce genre de propos déplacé.
Le terme despotisme te parait déplacé ? Il me semble que j'ai assez entendu de phrase du genre : "Celui qui fait a toujours le dernier môt : ce qui est du pur et simple despotisme..." ou comment imposer ces idées sans la moindre considération du point de vue des autres... donc désolé si la phrase te dérange, elle est adressé à toi aussi qu'aux autres développeurs et elle ne me parait pas du tout déplacée. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
participants (2)
-
desbois -
Tony Chemit