[JAVA] Librairie HelpGUI
Fermé
Posotaz
Messages postés
489
Date d'inscription
samedi 23 juin 2007
Statut
Membre
Dernière intervention
19 juin 2011
-
3 déc. 2007 à 00:43
Posotaz Messages postés 489 Date d'inscription samedi 23 juin 2007 Statut Membre Dernière intervention 19 juin 2011 - 4 déc. 2007 à 02:25
Posotaz Messages postés 489 Date d'inscription samedi 23 juin 2007 Statut Membre Dernière intervention 19 juin 2011 - 4 déc. 2007 à 02:25
A voir également:
- [JAVA] Librairie HelpGUI
- Waptrick java football - Télécharger - Jeux vidéo
- Jeux java itel football - Télécharger - Jeux vidéo
- Java apk - Télécharger - Langages
- Java décompiler - Télécharger - Langages
- Jeux java itel touche - Forum Mobile
1 réponse
Posotaz
Messages postés
489
Date d'inscription
samedi 23 juin 2007
Statut
Membre
Dernière intervention
19 juin 2011
225
4 déc. 2007 à 02:25
4 déc. 2007 à 02:25
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 :
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...
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...