Menu

[JAVA] Librairie HelpGUI [Fermé]

Posotaz 500 Messages postés samedi 23 juin 2007Date d'inscription 19 juin 2011 Dernière intervention - 3 déc. 2007 à 00:43 - Dernière réponse : Posotaz 500 Messages postés samedi 23 juin 2007Date d'inscription 19 juin 2011 Dernière intervention
- 4 déc. 2007 à 02:25
Bien le salut,

Plutôt que de programmer ça moi-même je me suis dit que ce serait bien de chercher s'il existait déjà une librairie Java pour afficher une fenêtre d'aide avec une TOC et où les fichiers de contenu seraient écrits en HTML.

Je l'ai trouvée, elle s'appelle HelpGUI (http://helpgui.sourceforge.net).

La démo fonctionne super mais si je télécharge le JAR et que je l'inclus à mon projet, je n'arrive pas à lui faire repérer mon dossier où se trouvent les fichiers toc.xml ainsi que les fichiers HTML. Je développe avec Eclipse et mon projet se constitue comme suit :
Dossier projet
	src
		mon package (view)
			Ma classe amorçe
			Eventuellement une autre classe
		un autre package
			Une classe
			Encore une autre classe
		...
	dossier des fichiers d'aide (htmlhelpfiles)
		toc.xml
		home.htm
		style.css
		...
	lib
		helpgui-1.1.jar

C'est donc directement sur le jar contenu dans mon dissier lib que j'ai fait le lien dans mon projet et en cochant ce jar. En fait la lien vers la librairie semble être effectué correctement puisqu'il ne met pas d'erreurs à ce niveau là.

Mon fichier toc.xml contient :
<?xml version="1.0" encoding="ISO-8859-1" ?>
<toc>
  <tocitem text="General">
    <tocitem text="Introduction"       target="home.htm" home="true"/>
  </tocitem>
</toc>

Ma classe amorçe contient ceci :
package view;

import javax.swing.JFrame;

import net.sourceforge.helpgui.gui.MainFrame;

public class HTMLHelpViewer /*extends JFrame*/ {
	
	public static void main(String[] args) {
		JFrame helpFrame = new MainFrame("./htmlhelpfiles", "plastic");
		File file = new File("./htmlhelpfiles");
		if(file.exists() && file.isDirectory()) {
			System.out.println("Le chemin est bon");
		}
		helpFrame.setVisible(true);
	}
	
}

Aucune erreur de compilation et dès que je lance, la fenêtre s'affiche avec tous les boutons... mais pas la TOC. En y regardant de plus près je lis sur la console :

java.lang.IllegalArgumentException: InputStream cannot be null
Le chemin est bon

Cette erreur se produit au moment d'instancier un objet MainFrame.

Le fait qu'il dise "Le chemin est bon" prouve bien que le dossier "htmlhelpfiles" existe bien. Donc c'est peut-être moi qui n'ai pas saisi un truc dans les explications fournies sur le site...

Si quelqu'un veut bien essayer de se pencher sur le problème je l'en remercierai.
Afficher la suite 

1 réponse

Posotaz 500 Messages postés samedi 23 juin 2007Date d'inscription 19 juin 2011 Dernière intervention - 4 déc. 2007 à 02:25
0
Merci
Bon...

Me doutant bien que le code ne devait pas être terrifiant, j'ai téléchargé les sources, créé un projet appropié et j'ai passé le tout en mode débugguage.

Au moment du parsage du fichier XML (la toc) et puis après au moment du chargement de l'URL de la page HTML (une partie du contenu), les concepteurs de cette librairie ont utilisé les méthodes getResource() et getResourceAsStream() de la classe courante qui ont pour but de se référer au classpath du projet.

Je m'en suis assuré en remplaçant les lignes originales des classes TocOpen et TextArea de ce package par :
saxParser.parse(/*TocOpen.class.getResourceAsStream(*/MainFrame.helpPath+"/toc.xml"/*)*/, handler);
url = new URL(/*TextArea.class.getResource(*/"file:"+MainFrame.helpPath+"/"+page.getTarget()/*)*//*.toString()*/);
Et là soulagement tout fonctionne (logique) !

Sauf que je ne comprends toujours pas ce mystère avec le classpath... Je place quand même mon dossier "htmlhelpfiles" à la racine du projet (donc là où se trouve le fichier .classpath) alors je ne comprends pas comment dans sa logique il ne cherche pas là dedans par défaut. J'ai même essayé d'inclure le dossier projet lui-même juste avant l'exécution dans l'onglet "classpath" et rien.

Conclusion

Ce viewer d'aide, comme il fallait s'y attendre, n'est ni plus ni moins qu'un JTree contrôlant le contenu d'un JTextPane avec tous ses défauts :

- Ne pensez pas pouvoir faire de l'XHTML. L'utilisation de balises auto-fermantes se traduira par l'impression du caractère ">" même si la balise sera interprétée. Déclarer le fichier HTML comme étant de l'XML ne changera rien... Java s'attend à recevoir de l'HTML tout court.

- Si vous essayez de définir le codage de la page HTML (<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />) avant la déclaration de la feuille de style (<link rel=stylesheet type="text/css" href="../style.css" />), cette dernière sera ignorée pour une raison obscure (pas de style c'est moche). On peut la mettre après par contre mais je ne sais pas si ça a un intérêt, je dis juste ça parce qu'une page correctement formée devrait contenir cette déclaration plutôt que de laisser le soin au navigateur de détecter automatiquement le charset avec les risques que cela encourt.

Ce ne sont que deux gros défauts trouvés en 5 minutes... imaginez comment pourrait virer la suite.

En conclusion, si vous avez une version online de votre documentation réalisée sous respect des standards du Web, vous êtes partis pour vous taper une deuxième version non standard... maintenir une version dynamique + une version statique risque de demander beaucoup d'efforts.

Dommage...