Liste de liens :
Liste de liens :
Utilisez la notion de workspace et de projects d'Eclipse pour profiter des services associés de controle du cycle de vie d'un projet , d'import, d'export, de propriétés, etc.
1 projet = 1 corpus binaire
1 projet contiendrait :
Description de la méthode de travail pour atteindre l'objectif
Organiser le projet pour qu'un moteur puisse se brancher et utiliser le corpus :
L'utilisation d'un ProjectScope (extension org.eclipse.ressources) permet de sauvegarder les préférences pour un projet, donc ici pour un corpus. Les préférences seront ensuite flushées dans des fichiers .prefs par plug-in dans le dossier du projet Eclipse/corpus.
Lorsque l'on récupère une préférence, l'ordre de recherche doit être le suivant :
Pour la persistance des résultats je propose d'utiliser le ProjectScope avec des noeuds dont le node qualifier est un identifiant de l'objet de résultat (ex. Object.toString() qui peut générer une chaîne du type “org.txm.progression.tbx.Progression@126546”). J'ai fait des tests avec cette méthode pour pouvoir gérer la réouverture des éditeurs de graphiques en conservant les paramètres que l'utilisateur a modifié dans le formulaire de paramètres (dans une même session TXM donc ici semi-persistance). Je procède ainsi pour récupérer et stocker les préférences locales à un résultat (pour l'instant en utilisant l'InstanceScope) :
A l'ouverture de l'éditeur, les paramètres de formulaire sont re-remplis à partir de ces scopes et le graphiques est regénéré à partir de ces scopes également et de l'objet de résultat s'il existe. Une classe TXMPreferences a été redéveloppée pour parcourir ces scopes et retourner les valeurs.
A partir de là on peut aller vers la vraie persistance en flushant le scope, ex. : InstanceScope.INSTANCE.getNode(Object.toString()).flush() qui génère un fichier avec le nom du noeud, ex. : “org.txm.progression.tbx.Progression@126546.prefs” contenant par exemple :
Bien qu'il n'est pas incompatible avec le système des IPersitable des IEditorInput il a sa propre vie en dehors d'un plug-in de type UI ce qui semble une bonne chose pour le portail. Au niveau de la RCP, on pourrait le coupler avec ce système en utilisant les méthodes isDirty(), etc. et flushant uniquement quand l'utilisateur fait “save” mais pour les charts ça me semble abusif.
Pour la récupération, à l'ouverture d'un projet il suffirait de récupérer et parcourir les noeuds du ProjectScope, le node qualifier contenant le nom de la classe on peut recréer les objets via l'API Java de réflexion. Pour des tests dès maintenant on pourrait parcourir les noeuds du InstanceScope.INSTANCE. Le système a été implémenté dans les nouvelles extensions org.txm.textsbalance et org.txm.wordcloud, sans la “vraie” persistance, juste pour pouvoir réouvrir un noeud de résultat en conservant les paramètres.
On utilise actuellement le InstanceScope pour la gestion de toutes les préférences (workspace, corpus, index, etc…).
On utilise actuellement l'InstanceScope ne contient plus que les préférences générales de TXM.
Les ProjectScope contiennent les préférences des corpus et de leurs résultats.