Outils pour utilisateurs

Outils du site


public:plugins_structure

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
public:plugins_structure [2014/12/12 06:48]
sebastien.jacquot@univ-fcomte.fr
public:plugins_structure [2017/07/04 11:23] (Version actuelle)
matthieu.decorde@ens-lyon.fr Links to prive:nommage_symboles_externalisation changed to public:nommage_symboles_externalisation
Ligne 11: Ligne 11:
 Ce développement est étroitement lié à l'​architecture des préférences TBX et RCP, voir : [[public:​preferences_system|Architecture des préférences TBX et RCP]]. Ce développement est étroitement lié à l'​architecture des préférences TBX et RCP, voir : [[public:​preferences_system|Architecture des préférences TBX et RCP]].
 Le travail/​remaniement risque d'​être conséquent et générateur de divers problèmes et bugs, j'​aurais tendance à proposer un cycle de développement long pour ces devs (6 mois ?). L'​interdiction par la RCP d'​avoir des dépendances cycliques entre plugins risque d'​engendrer de la modification et de la restructuration du code source en lui-même. Il faudra ensuite notamment revalider toutes les fonctionnalités de TXM. Le travail/​remaniement risque d'​être conséquent et générateur de divers problèmes et bugs, j'​aurais tendance à proposer un cycle de développement long pour ces devs (6 mois ?). L'​interdiction par la RCP d'​avoir des dépendances cycliques entre plugins risque d'​engendrer de la modification et de la restructuration du code source en lui-même. Il faudra ensuite notamment revalider toutes les fonctionnalités de TXM.
 +
 +NOTE: tbx.chartengine.jfreechart embarque des bribes de code relatif à l'UI pour le futur port vers TXM Portal. Mais certaines de ces fonctionnalités ne seront sans doute pas mutualisées entre RCP et Portal, il faudrait revoir cela, je pense notamment à une partie de la gestion des événements/​entrées utilisateur (bien qu'une abstraction au niveau TBX pourrait être intéressante pour mutualisation GWT/SWT).
  
 ===== Solution ===== ===== Solution =====
Ligne 94: Ligne 96:
     * statsengine (inutile dans les plugins RCP ?)     * statsengine (inutile dans les plugins RCP ?)
  
-Les bonnes pratiques semblent préconiser de faire un fragment étendant le plugin hôte pour chaque langue (c'est ce que fait la team Eclipse apparemment),​ cela complexifie la traduction et multiplie les projets Eclipse mais cela a aussi ses avantages non négligeables,​ voir notamment : [[prive:nommage_symboles_externalisation|Nommage des symboles d'​externalisation]]. Est-ce que les avantages sont suffisants dans le cadre de TXM pour que l'on parte là-dessus malgré la complexification ?+Les bonnes pratiques semblent préconiser de faire un fragment étendant le plugin hôte pour chaque langue (c'est ce que fait la team Eclipse apparemment),​ cela complexifie la traduction et multiplie les projets Eclipse mais cela a aussi ses avantages non négligeables,​ voir notamment : [[nommage_symboles_externalisation|Nommage des symboles d'​externalisation]]. Est-ce que les avantages sont suffisants dans le cadre de TXM pour que l'on parte là-dessus malgré la complexification ?
  
  
Ligne 169: Ligne 171:
  
 NOTE: avant cela, trouver un moyen de ne plus être obligé d'​inclure les .class de la Toolbox complète utilisés par Groovy dans les build, cela double la taille du JAR TBX et de plus ça semble difficilement compatible avec le découpage en plugins. NOTE: avant cela, trouver un moyen de ne plus être obligé d'​inclure les .class de la Toolbox complète utilisés par Groovy dans les build, cela double la taille du JAR TBX et de plus ça semble difficilement compatible avec le découpage en plugins.
 +
 +NOTE: we may need to simplify the management of all the projects of TXM by using a Team Projet Set (TPS) or using Maven, Buckminster,​ etc. See: [[http://​www.eclipseonetips.com/​2010/​01/​25/​checkout-multiple-projects-automatically-into-your-eclipse-workspace/​]]
 +This will be especially useful/​needed when we'll split the layers and commands to separated plug-in projects.
 +
  
   * découper/​regrouper/​réfactorer les commandes TBX et RCP dans des packages par commande, ex. org.txm.tbx.ca,​ org.txm.rcp.concordance,​ etc.   * découper/​regrouper/​réfactorer les commandes TBX et RCP dans des packages par commande, ex. org.txm.tbx.ca,​ org.txm.rcp.concordance,​ etc.
     * en profiter pour renommer les projets de base org.txm.tbx et org.txm.rcp     * en profiter pour renommer les projets de base org.txm.tbx et org.txm.rcp
   * dispatcher/​décentraliser toutes les chaînes des fichiers messages.properties,​ messages_fr.properties,​ etc. dans des sous packages du type org.txm.tbx.ca.messages   * dispatcher/​décentraliser toutes les chaînes des fichiers messages.properties,​ messages_fr.properties,​ etc. dans des sous packages du type org.txm.tbx.ca.messages
-    * en profiter pour renommer les symboles/​constantes liés aux chaînes avec des noms explicites (voir les symboles utilisés par exemple dans le charts engine où j'ai essayé d'​être explicite et la page: [[prive:nommage_symboles_externalisation|Nommage des symboles d'​externalisation]])+    * en profiter pour renommer les symboles/​constantes liés aux chaînes avec des noms explicites (voir les symboles utilisés par exemple dans le charts engine où j'ai essayé d'​être explicite ​[[http://​svn.code.sf.net/​p/​txm/​code/​trunk/​Toolbox/​trunk/​org.textometrie.toolbox/​src/​java/​org/​txm/​tbx/​chartsengine/​base/​messages/​messages.properties]] ​et la page: [[nommage_symboles_externalisation|Nommage des symboles d'​externalisation]])
   * implémenter un système de Store RCP pour la TBX   * implémenter un système de Store RCP pour la TBX
   * dispatcher/​décentraliser toutes les préférences de la TBX et de la RCP dans des sous packages du type org.txm.tbx.ca.preferences   * dispatcher/​décentraliser toutes les préférences de la TBX et de la RCP dans des sous packages du type org.txm.tbx.ca.preferences
Ligne 183: Ligne 189:
   * définir si le charts engine devient un plugin obligatoire et/ou si on éclate les fonctions de génération de graphiques dans chaque plugin   * définir si le charts engine devient un plugin obligatoire et/ou si on éclate les fonctions de génération de graphiques dans chaque plugin
     * (a priori oui pour l'​éclatement et oui pour la non optionnalité de la base abstraite du code)     * (a priori oui pour l'​éclatement et oui pour la non optionnalité de la base abstraite du code)
 +    * utiliser le concept de Renderers/​Producers/​ChartsCreators. En créer pour chaque type de graphique et qui seront donc stockés au niveau du plugin de la fonctionnalité. Stocker dans le charts engine une pile de Renderers/​Producers. Définir une méthode du type createChart(Object object), l'​object ici serait majoritairement un objet de type TXMResult mais a priori tous les résultats dans TXM n'​héritent pas de TXMResult, à revérifier. Voir aussi comment passer les paramètres à cette méthode car actuellement les méthodes du type createProgressionChart() prennent beaucoup plus de paramètres que l'​objet Progression. Ensuite, par exemple un truc du style dans createChart(),​ getRendererFor(progression).createChart() => commencer par tester dans WordCloud
   * définir si on tente de réintroduire une abstraction des moteurs de corpus et de statistiques   * définir si on tente de réintroduire une abstraction des moteurs de corpus et de statistiques
   * une fois le découpage en packages fait et que tout fonctionne, commencer le découpage des packages en projets/​plugins et créer les projets de features associés   * une fois le découpage en packages fait et que tout fonctionne, commencer le découpage des packages en projets/​plugins et créer les projets de features associés
public/plugins_structure.1418363336.txt.gz · Dernière modification: 2014/12/12 06:48 par sebastien.jacquot@univ-fcomte.fr