On Tue, 5 Apr 2011 22:23:21 +0200 Julien Ruchaud <julien.ruchaud@codelutin.com> wrote:
Le Tue, 5 Apr 2011 17:33:46 +0200, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
Salut,
Ce document est la pour présenté la bonne utilisation de ApplicationConfig d'après moi. Il est la comme base de départ pour trouver la meilleur utilisation possible.
Etendre la classe ApplicationConfig dans son programme ou sa librairie est une mauvaise idée, surtout lorsqu'on utilise cette classe en argument de méthode, car on va finir par avoir plusieurs types de ApplicationConfig incompatibles entre elles et on ne pourra plus utiliser ApplicationConfig car il faudra passer par de la recréation dans le bon enfant de ApplicationConfig a partir des properties d'une autre. Je ne suis pas d'accord dans tous les cas.
Il peut être très bien de pouvoir utiliser ApplicationConfig (une surcharge en fait) comme un Bean, typiquement dans une application finale. Le fait d'avoir des getter et setter c'est souvent plus pratique qu'un helper avec des méthodes statiques. De plus avec un vrai objet de config, on peut aussi avoir une interactions avec des PropertychangeListener et c'est pas mal. Moi je suis vraiment pas convaincu de cette utilisation pour une application finale (en tout pour du swing qui utilise beaucoup la norme JavaBean). L'utilisation ensuite dans une librairie de cette surcharge d'ApplicationConfig ne posera jamais un problème car c'est toujours du ApplicationConfig. Suis-je clair ? Par contre pour les librairies oui il faut bien faire comme ça et donc pour moi y'a pas une manière universelle de faire.
Pour éviter cela, la bonne façon lorsqu'on utilise ApplicationConfig serait de créer un MesOptions.java et MesActions.java qui seraient des enumerations dans lequel on défini l'ensemble des caractéristiques (nom, description, valeur par defaut, type, alias, ...)
Est-ce que quelqu'un voit un inconvénient à cette bonne pratique ?
Non
comment ca marcherait ? =======================
Ajout de méthode spécifique pour accéder facilement a une option ----------------------------------------------------------------
methodes pour acceder rapidement aux options si on le souhaite sur l'enum ex: - getMonOptionFichier(ApplicationConfig config): File - getUneAutreOption(ApplicationConfig config): String
Ces methodes feraient simplement: - return config.getConfigAsFile(MON_OPTION_FICHIER); - return config.getConfig(UNE_AUTRE_OPTION);
Les enum implanteraient des interfaces spécifiques --------------------------------------------------
L'enum pour les options devrait implanter une interface spécifique avec les méthodes: - getDescription(): String - getValue(ApplicationConfig): String - getAliases:String[] - ...
Et le constructeur de l'enum aurait en argument: - String key - String description - String default value - Class type - boolean transient (indique que l'option ne sera jamais sauvé sur disque) - boolean readonly (indique que l'option ne peut pas changer de valeur) - String ... aliases
Init de ApplicationConfig -------------------------
plusieurs constructeurs possibles:
- new ApplicationConfig(); - new ApplicationConfig(MesOptions.class); - new ApplicationConfig(MesOptions.class, MesActions.class); ...
ApplicationConfig config = new ApplicationConfig(...); config.parse(args); config.action(level);
Lors du new si les enums sont passées en argument, l'ApplicationConfig les utilise pour s'initialiser
Mise en commun de certains besoins ----------------------------------
Du coup, il est possible de mettre par exemple la methode Help dans ApplicationConfig qui retourne la chaine 'usage' a afficher.
Ce qu'il reste a faire ----------------------
Il n'y a pas grand chose a faire, vu qu'on a déjà une interface existante pour les options (OptionDef), il manque juste les alias.
-> version majeure de nuiton-utils car on casse une api.
Et il faut juste le mettre en place de cette façon dans les projets (surtout les libs) qui l'utilise et y penser pour les prochains.
A ma conaissance seul wikitty utilise ApplicationConfig -> donc rien à faire ? :)
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com