nouveaux modules nuiton-updater et nuiton-config
Ola, Chose promise,... Je voudrais qu'on ai une petite discussion autour d'ApplicationConfig vu qu'on (je) le retravaille, on peut se permettre des changements d'api et y'en un certain nombre que je voudrais voir apparaitre (ou disparaitre). Particulièrement, ne plus utiliser des Inner classes (pour des api publiques) car dans le code c'est un peu la looze d'avoir des ApplicationConfig.OptionDef et autres, vu que le module est consacré à ApplicationConfig, j'ai bien envie de décapsuler tout ça (ce que j'ai déjà fait pour les api publiques d'ApplicationUpdater). Le but serait aussi de ne plus avoir une classe ApplicationConfig qui fait 2800 lignes et 6 inner classes :( J'avais rajouté à une certaine époque du comportement (propertychange,...) dans Applicationconfig, avec le recul je me rends compte que ce n'est plus très pertinent, je voudrais donc aussi revenir là-dessus, à savoir: - avoir un objet ApplicationConfig neutre qui fait juste lire, écrire des options / actions (partie technique, besoin serveur...) - avoir un autre objet qui encapsule un ApplicationConfig (plus pour le métier / partie client) et qui lui pourrait être PropertyChange... Je voudrais aussi revoir l'api des OptionDef, perso avec le recul utiliser des enums, pour moi c'est pas forcement nécessaire, et je voudrais avoir un object SimpleOptionDef qui contient tout ce qui définit une option (bon ok les énumérations en plus pourront l'utiliser en délégation plutot que de tout redéfinir à chaque fois... A vos avis, remarques, (commits! j'ose espérer :)) Tony (qui en a marre des final static public :( [0] et aussi des /** to use log facility, just put in your code: log.info(\"...\"); */ [1]). [0] acter en réuniondev qu'on utilisait la convention de *sun*, jamais mis en pratique par certains... [1] Ok merci je suis un neu-neu et je fais du java dans un monde de bisounours, ok je veux qu'on m'aprenne à écrire un log :( Ok je sors! ... de ma grotte! dixit http://fr.wikipedia.org/wiki/All%C3%A9gorie_de_la_caverne
Le 26/02/2013 09:36, Tony Chemit a écrit :
Je voudrais qu'on ai une petite discussion autour d'ApplicationConfig vu qu'on (je) le retravaille, on peut se permettre des changements d'api et y'en un certain nombre que je voudrais voir apparaitre (ou disparaitre).
Particulièrement, ne plus utiliser des Inner classes (pour des api publiques) car dans le code c'est un peu la looze d'avoir des ApplicationConfig.OptionDef et autres, vu que le module est consacré à ApplicationConfig, j'ai bien envie de décapsuler tout ça (ce que j'ai déjà fait pour les api publiques d'ApplicationUpdater).
Le but serait aussi de ne plus avoir une classe ApplicationConfig qui fait 2800 lignes et 6 inner classes :(
J'avais rajouté à une certaine époque du comportement (propertychange,...) dans Applicationconfig, avec le recul je me rends compte que ce n'est plus très pertinent, je voudrais donc aussi revenir là-dessus, à savoir:
- avoir un objet ApplicationConfig neutre qui fait juste lire, écrire des options / actions (partie technique, besoin serveur...) - avoir un autre objet qui encapsule un ApplicationConfig (plus pour le métier / partie client) et qui lui pourrait être PropertyChange...
Je voudrais aussi revoir l'api des OptionDef, perso avec le recul utiliser des enums, pour moi c'est pas forcement nécessaire, et je voudrais avoir un object SimpleOptionDef qui contient tout ce qui définit une option (bon ok les énumérations en plus pourront l'utiliser en délégation plutot que de tout redéfinir à chaque fois... Tu peux en dire un peu plus sur ce que tu imagines ? Perso j'avoue que les Enum me conviennent (dans ce cadre du moins).
À part ça, je suis tout à fait d'accord avec le reste de ton analyse. Cordialement, Arnaud
On Tue, 26 Feb 2013 09:36:03 +0100 Tony Chemit <chemit@codelutin.com> wrote:
- avoir un objet ApplicationConfig neutre qui fait juste lire, écrire des options / actions (partie technique, besoin serveur...) - avoir un autre objet qui encapsule un ApplicationConfig (plus pour le métier / partie client) et qui lui pourrait être PropertyChange...
J'ai du mal a voir comment on peut faire ca sans que ApplicationConfig de base le fasse déjà ? Comment vois-tu la chose (par héritage et surcharge des set) ? -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
Le 26/02/2013 09:36, Tony Chemit a écrit :
Ola, Petit retour sur le module nuiton-config.
Je trouve dommage qu'il dépendent toujours de nuiton-utils et donc ca ne voit pas l’intérêt. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
On Tue, 02 Apr 2013 18:17:52 +0200 Eric Chatellier <chatellier@codelutin.com> wrote:
Le 26/02/2013 09:36, Tony Chemit a écrit :
Ola, Petit retour sur le module nuiton-config.
Je trouve dommage qu'il dépendent toujours de nuiton-utils et donc ca ne voit pas l’intérêt.
l'idée ça serait à terme surtout de ne plus avoir de nuiton-utils mais juste quelques libs spécialisés et plus de StringUtil et autre foure tout anti contributions à commons et autre projet communautaire. Enfin c'est la vision que je défends. Je ne sais pas le gap pour supprimer la dep vers nuiton-utils, m'est avis qu'il n'y a pas grand chose à changer. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Tue, 02 Apr 2013 18:17:52 +0200 Eric Chatellier <chatellier@codelutin.com> wrote:
Le 26/02/2013 09:36, Tony Chemit a écrit :
Ola, Petit retour sur le module nuiton-config.
Je trouve dommage qu'il dépendent toujours de nuiton-utils et donc ca ne voit pas l’intérêt.
Les dépendances sont : import org.nuiton.util.ObjectUtil; import org.nuiton.util.RecursiveProperties; import org.nuiton.util.SortedProperties; import org.nuiton.util.Version; import org.nuiton.util.converter.ConverterUtil; J'en ai déjà supprimé vers FileUtil et StringUtil, mais il reste donc. Pour les xxxUtil on doit bien pouvoir les supprimer, mais pour Version c'est plus compliqué car y'a vraiment une plus-value. Un nouveau module nuiton-version ? :) tony.
participants (4)
-
Arnaud Thimel -
Benjamin POUSSIN -
Eric Chatellier -
Tony Chemit