Liste de liens :
Liste de liens :
Ces spécifications correspondent au Ticket #269.
Voir la section Avancement dans l'élaboration de la solution pour la description des phases de développement.
Marche à suivre :
TBD TXM Portal: GWTHighChartsEngine : produire directement du JavaScript ou du code Java GWT ? Le problème du Java GWT et qu'il faudra le pré-compiler donc a priori il n'y aurait aucun gain à générer du Java. Utiliser aussi un ComponentsProvider pour TXM Portal ?
TXM Portal : voir aussi : http://www.jfree.org/jfreechart/api/javadoc/org/jfree/chart/ChartUtilities.html#getImageMap%28java.lang.String,%20org.jfree.chart.ChartRenderingInfo,%20org.jfree.chart.imagemap.ToolTipTagFragmentGenerator,%20org.jfree.chart.imagemap.URLTagFragmentGenerator%29. JFC permet de créer une imagemap que l'on peut inclure dans du HTML et permettant d'exporter les tool tips (dans quelle mesure ?) et d'ajouter des liens hypertextes sur les items. Voir aussi : http://faresibneyyusuf.blogspot.fr/2008/07/gwt-with-jfreechart-in-jbossportal.html pour un exemple génération dynamique et de visualisation de jpeg depuis JFC avec JBossPortal. Autre lien utilisant des imagemap : http://www.jfree.org/phpBB2/viewtopic.php?t=19080.
TXM Portal : voir en premier lieu le projet Gimv (Google Web Toolkit™ Image Viewer) : https://code.google.com/p/gimv/wiki/UserGuide#JFreeChart_sample et http://code.google.com/p/gimv/source/browse/trunk/gimv/lib/samples/jfreechart?spec=svn3&r=3, dédié à la visualisation d'images interactives.
Après tests de l'exemple fourni, le couple Gimv / JFreeChart semble prometteur et permettrait de produire des graphiques via le JFCChartsEngine, donc de conserver les thèmes graphiques JFC créés et de profiter des fonctionnalités de base apportées par Gimv. L'intérêt ici est de pouvoir profiter de certaines fonctionnalités de JFC, notamment du recalcul du graphique par JFC (changement d'échelle) au zoom/pan, par exemple) de manière asynchrone. Il faudrait tester la compatibilité avec tous les navigateurs, car le projet Gimv semble n'avoir pas été mis à jour depuis 2010. Lien vers le war : gimv_jfreechart_sample.zip. Actuellement je n'ai pas bien compris si le recalcul du graphique était réellement fait via un nouvel appel à JFC qui créerait un nouveau JPG, je pense que c'est ce qui se produit mais je ne trouve pas de nouveau JPG dans le dossier tmp de Tomcat lors d'un zoom ou d'un pan.
Suite aux recherches et aux solutions envisagées, la solution retenue est la suivante :
La solution s'articule sur 3 composants principaux :
TODO : TXM Portal :
Utiliser aussi un ComponentsProvider pour TXM Portal ?
Voir : solution 3
Il s'agit ici de centraliser toutes les fonctionnalités de production de graphiques dans un seul composant. Le composant définit une interface contenant des méthodes de production de graphiques à partir de tout type de résultats.
Un moteur courant est défini par une préférence et il est stocké au niveau de la Toolbox. Le moteur prend en entrée un objet de résultat TXM et produit un Object en sortie, en fonction de son implémentation et de sa configuration. Le RChartsEngine, par exemple, prend en entrée un objet CA et produit un fichier SVG, PNG, etc. Le JFCChartsEngine, lui, produit des objets Java JFreeChart.
Il s'agit ici de centraliser la création de composants SWT (en particulier d'EditorPart) en fonction d'un objet de résultat TXM et du moteur de production de graphiques courant.
Recherche sur une terminologie pour englober tous les types de graphiques. Plusieurs mots anglais : chart, graphic, graph, plot. Il semblerait que “plot” en anglais n'est pas un nom mais plutôt un verbe qui veut dire “tracer un graphique”. “graphic” dans le sens “graphique de stats” ne semble pas s'utiliser comme nom mais uniquement comme adjectif. Quant à lui, “graphic” en tant que nom, semble signifier plutôt “graphisme” (comme dans Graphics Engine). Pour englober tout type de graphiques il semblerait qu'il ne reste que “chart” et “graph” mais comme “graph” signifie également “graphe” en français ça semble trompeur mais de plus nous aurons également a priori besoin de réserver ce mot pour qualifier les graphes dans le code source.
Le choix a donc été fait d'utiliser “chart” dans le code source pour définir la “racine” de tout type de graphiques.
[SJ: les tests/questions suivants n'ont semble-t-il pas été traités lors de l'apha 0.7.6, je les transfère dans la roadmap 0.7.7 avant de les trier]