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