Liste de liens :
Liste de liens :
Améliorer l'architecture des préférences et propriétés de la Toolbox et de la RCP :
Je pense [SJ] que cette phase doit être faite avant, voire en même temps, que le découpage en plugins des projets TBX et RCP.
L'utilisation de deux systèmes différents de gestion des préférences pour la TBX et la RCP complique énormément l'ajout, l'édition et la définition des valeurs par défaut des préférences. Il faut définir des constantes dans la TBX, les redéfinir dans la RCP, copier les préférences d'un niveau vers l'autre, etc.
D'autre part, il faut aussi définir les valeurs par défaut des nouvelles préférences dans le fichier install.prefs, ce qui complexifie encore. Par exemple si un fichier org.txm.rcpapplication.prefs existe mais que la préférence n'existe pas, sa valeur par défaut est définie en dur dans le code mais si le fichier org.txm.rcpapplication.prefs n'existe pas les valeurs par défaut doivent être définies dans install.prefs. Pour ce point j'aurais tendance [SJ] à proposer de ne plus utiliser le fichier install.prefs et de tout coder en dur, ce qui supprimerait déjà un endroit supplémentaire de gestion des prefs générateur d'oubli et d'erreurs.
Seule la RCP est capable de sauvegarder les préférences. Elles sont sauvegardées dans le fichier “org.txm.rcpapplication.prefs” où “org.txm.rcpapplication” est en faite l'ID de plugin de la RCP. La Toolbox autonome (comme dans le portail) ne fait que lire un fichier properties.
Par ailleurs, les valeurs par défaut des préférences RCP ne sont pas systématiquement définies, ainsi “Restore default” sur une page de préférence RCP fonctionne mal.
Anciennes notes :
Questions :
Avec la séparation par plugins, il y aura a priori de toute façon un Store par plugin ? Et le plugin pourra alors se charger d'initialiser lui-même ses propres préférences et de définir les valeurs par défaut.
TODO: Reste à définir le nom de fichier des prefs globales/partagées, je propose d'utiliser directement Platform.getProduct().getId() pour récupérer dynamiquement le nom du fichier global/partagé des préférences dans chaque plugin. Reste aussi à définir si les préférences des plugins optionnels doivent être stockées dans le fichier global des prefs ou bien dans des fcihiers à part. Je propose de les stocker dans des fichiers à part en utilisant l'id du bundle comme preference node qualifier, ne connaissant pas le comportement lors de la désinstallation d'une plugin optionnel (à mon avis les prefs restent dans le fichier).
Première proposition, testée avec le plugin WordCloud, tout fonctionne.
Dans la TBX (ou tout plugin de type non UI) :
public static final String PREFERENCE_NODE = Platform.getProduct().getId(); // pour utiliser le fichier global/partagé ou bien :
public static final String PREFERENCE_NODE = "org.txm.tbx.wordcloud"; // pour sauver les prefs dans un fichier org.txm.tbx.wordcloud.prefs
public static final String MAXWORDS = "wordcloud_maxwords"; //$NON-NLS-1$ public static final String FMIN = "wordcloud_fmin"; //$NON-NLS-1$ public static final String ROT = "wordcloud_rotper"; //$NON-NLS-1$ public static final String RANDOMCOLOR = "wordcloud_randomcolor"; //$NON-NLS-1$
@Override public void initializeDefaultPreferences() { Preferences defaultPreferences = DefaultScope.INSTANCE.getNode(PREFERENCE_NODE); defaultPreferences.put(MAXWORDS,"50"); defaultPreferences.put(FMIN, "2"); defaultPreferences.put(ROT, "10"); defaultPreferences.put(RANDOMCOLOR, "false"); }
Dans la RCP (ou tout plugin de type UI)
public static ScopedPreferenceStore getNewPreferenceStore() { return new ScopedPreferenceStore(ConfigurationScope.INSTANCE, WordCloudPreferencesInitializer.PREFERENCE_NODE); }
setPreferenceStore(getNewPreferenceStore());
En utilisant tout ça voici ce qu'il se passe :
Au sujet de l'utilisation de Platform.getProduct().getId(), attention si on utilise plusieurs products.
TODO: Il faudrait définir nos propres extensions points pour TXMPreferenceInitializer et TXMPreferencePage notamment car du code peut être mutualisé, ex. “public static ScopedPreferenceStore getNewPreferenceStore()”. Ex. org.txm.tbx.preferences et org.txm.rcp.preferencePage
Voir également la classe existante /org.txm.rcp/src/main/java/org/txm/rcpapplication/TxmPreferences.java une partie du code est à reprendre et à mettre dans une classe abstraite mais au niveau de la TBX, pour les getInt(), getString(), etc. ex. : public abstract TXMPreferencesInitializer extends AbstractPreferenceInitializer - public final String PREFERENCE_NODE = “org.txm.tbx.wordcloud”; - getInt(), getString(), etc.utilisant Platform.getPreferencesService().getString(REFERENCE_NODE, preferenceName, “”, null). Ceci implique de créer un plugin supplémentaire org.txm.tbx.preferences pour qu'il soit utiliser par le host TBX mais aussi par les plugins de contribution.
Voir https://www.eclipse.org/forums/index.php/t/1082107/ et https://wiki.eclipse.org/FAQ_What_is_a_preference_scope%3F
La classe TXMPreferences utilise l'InstanceScope (et non pas le ConfigurationScope) et c'est ce scope qui est exporté lorsque l'on utilise l'export des préférences dans TXM.