Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/07200.jsonl.gz/1253

Lorsque j'ai commencé le cours Staf2X, j'avais quelques bases en programmation qui venaient de mes études antérieures et plus particulièrement de la première année STAF. Mais je n'avais jamais travaillé avec un "vrai" langage de programmation, i.e. un langage nécessitant un compilateur, une stricte déclaration des variables, orienté objet, etc.
Si la syntaxe de base de JAVA est relativement simple, sa complexité vient des "packages" que l'on peut utiliser. Cela nécessite de lire beaucoup de documentation et de passer quelques temps avec chacun de ces packages afin de commencer à les maîtriser.
Mes objectifs pour ce cours étaient les suivants:
Pour cela, j'ai travaillé sous forme de déclinaisons. J'ai commencé par des exercices simples que j'ai essayé d'enrichir au fur et à mesure. On trouve donc une déclinaison GUI/JDBC et une autre pour j2ee (java serveur side)
Table des matières
Pour ce premier programme, le but principal était tout simplement de faire quelque chose qui marche, i.e. qui compile et qui fasse a peu prêt ce que je voulais. J'ai fait une petite interface GUI avec deux boutons "oui" et "non". L'étape suivante a été de comprendre la programmation évènementielle en capturant les évènement "onclick" sur les boutons. Ce qui m'a posé le plus de problème de compréhension était l'ajout du "windowListeer" qui permet de fermer l'application quand on clique sur le bouton "fermer" de la fenêtre. En effet, la méthode addWindowListener() prend en argument un objet implémentant l'interface WindowListener. Il existe une classe abstraite WindowAdapter implémentant cette interface, mais, comme elle est abstraite, on ne peut pas l'instancier. Il y a alors 2 solutions:
C'est pour la deuxième solution que j'ai opté car c'est celle qui m'a le mieux permis de comprendre ce que je faisais dans un premier temps. Il semble cependant que, en matière de programmation et d'execution, ce soit la première solution qui soit la plus efficace.
Table des matières
Pour ce deuxième exercice, j'ai voulu explorer un peu les possibilité de swing en matière de GUI. Je voulais également expérimenter un peu avec JDBC et les bases de données.
En matière de Gui, j'ai utilisé un panneau à onglet: un onglet pour l'ajout de données et un autre pour la consultation et la mise à jour. Mon plus gros problème a été de comprendre comment les éléments graphiques étaient disposés sur l'application par le layout manager. En fait, je ne suis pas encore sûr d'avoir compris exactement la façon dont le boxlayout fonctionne... mais j'ai réussi à faire à peut prêt ce que je voulais faire.
Table des matières
L'application est exactement la même que la précédente. Mais ici le design est différent. En effet, pour cette version le code est clairement séparé dans 2 classes différentes: une classe pour la communication avec la base de données, une autre pour l'interface graphique lui même.
Dans cet exercice, j'ai également essayé de me familiariser avec des standards de programmation (nom de variables commentaire). Je me suis inspiré des conseils donnés par Scott W. Ambler dans son document "Writing Robust Java Code" (si ce document n'est pas disponible, vous pouvez consulter une copie locale). J'ai notamment appliqué le standard javadoc pour la documentation, ce qui m'a permis de générer automatiquement la documentation de ma classe UserDbManager qui communique avec la base de données.
Table des matières
Pour finir sur cette déclinaison GUI/JDBC, j'ai essayé de transformer ma classe de type JFrame en Japplet afin de pouvoir l'intégrer à une page WEB. Ici, j'ai eu quelques problèmes que je n'ai d'ailleurs toujours pas résolus.
Cet exemple est donc non fonctionnel.
Table des matières
Pour tous les exercices qui suivent, je suis parti sur la base d'un questionnaire sur la spéléologie que j'avais réalisé en php lors de la première année Staf. Pour consulter l'exercice original, voir la rubrique staf14 dans mes travaux de première année.
Table des matières
Jhtml est un langage qui, à l'instar de php, permet d'inclure des scripts dans des pages html. Les pages sont ensuite exécutées par le serveur avant d'être renvoyées au client. Mis à part le langage utilisé pour les scripts (java au lieu de php), la grande différence avec php se situe à 2 niveaux:
Pour ce premier essai, mon objectif était le même que pour mon premier GUI: faire quelque chose qui marche. J'ai donc simplement repris le code php et j'ai cherché à le transformer en Jhtml en faisant le moins de modifications possibles. Bien sur, en faisant cela, je n'ai pas utilisé du tout les possibilités offertes par la puissance de java coté serveur. Mais cela m'a néanmoins permis d'apréhender les quelques difficultés liées à cette technologie comme celle du debogage, les problèmes de passage de variables, etc. Bien que j'ai essayé de cantoner les modifications à faire à leur strict minimum, il a fallu en introduire un certain nombre (clauses try... catch.... pour capturer les erreurs d'éxécution, capture des variables...).
Je ne peux pas vous fournir d'url pour visualiser le résultat car le server java "Jserv" qui permettait d'éxécuter les pages Jhtml n'est plus en prodution à tecfa. Il a été remplacé par un serveur Tomcat. Ce serveur, comme son prédécesseur, permet d'éxécuter des servlet et supporte également un type de script de page html, le langage JSP qui a totalement supplanté Jhtml et qui est devenu un standard. Nous verrons plus loins une application de cette technologie.
Table des matières
Afin de comprendre correctement, la transformation qui s'opère lors de la traduction d'une page Jhtml (ou JSP) en servlet, j'ai choisi de transformer l'exercice précédent directement en servlet. La transformation à été plutot simple. Elle se résume à incorporer les partie "html pur" dans des variables qui seront écrites dans la page de résultat et d'implémenter quelques objets permettant d'interagir avec le serveur pour capturer les requêtes et envoyer des résultats.
Bien entendu, le résultat obtenu est strictement identique. Cependant, on peut noter quelques différences en matière de développement. En effet, l'écriture du programme se fait ici totalement en java ce qui a deux conséquences qu'on pourrait opposer:
A l'heure où j'écris ces lignes, la démonstration ci-dessus se trouve sur un serveur Tomcat 4.0 en test à tecfa. Je prie, par avance, les lecteurs de bien vouloir m'excuser si cette démonstration ne fonctionne plus. Cependant, si vous voulez vraiment y accéder, faites le moi savoir et j'essaierai de la remettre en route dans les meilleurs délais.
Table des matières
Pour ce dernier exercice, mes objectifs étaient nombreux et plus ambitieux.
En ce qui concerne la séparation du code permettant de calculer le résultat, j'ai développé un JavaBean très simple. Ce Bean est utilisé par la page fournissant le questionnaire et donnant les réponses. Ceci rend le développement de la page JSP très simplifié puisque tout se résume a faire quelques actions en utilisant des tags xml-like:
Instancier le Bean:
<jsp:useBean id="answers" class="my.SpeleoBean" />
Envoyer les valeurs des réponses au Bean
<jsp:setProperty name="answers" property="*" />
Récupérer les valeurs des feedbacks (ici exemple pour la question 1)
<jsp:getProperty name="answers" property="rep1Feedback" />
Le résultat donne une page jsp qui ne contient quasiment que du html et quelques tags jsp. La lecture en est grandement facilitée, et la modification très simple. Le but n'est cependant pas tout a fait atteint puisque le Bean renvoit quelques tags html dans les feedbacks. Ceci n'est pas souhaitable dans le cas d'une véritable application professionelle puisque toute la mise en forme devrait se trouver dans la page JSP à la disposition de la personne s'occuppant du layout afin de laisser au développeur le soin de calculer les bonnes valeurs à retourner.
Le developpement du Bean a été énormément facilité par l'utilisation de Forte 3.0 qui contient un module de développement spécifique. Il suffit de lui donner le nom des champs que l'on veut voir apparaitre (rep1, rep1Feedback, etc.) et si ces champs sont "readable", "writable" ou les deux. Le squelette du code est alors automatiquement généré. Il est même possible d'intégrer de façon très simple des Listener générant des évènements lorsqu'un champ change de valeur. J'ai renoncé à utiliser cette possibilité par manque de temps.
Enfin, Forte 3.0 comporte un module permettant d'exporter l'application sous forme de Web Archive (.war). Il s'agit en fait d'un simple fichier Zip contenant l'ensemble des fichiers et classes de l'application ainsi qu'un peu d'information permettant à un serveur compatible (Tomcat 4.0 par exemple) d'installer l'application de façon automatique. Il suffit alors de poser ce fichier au bon endroit (<tomcathome>/webapps/ pour tomcat), de démarer le serveur et l'application est alors immédiatement accessible.
A l'heure où j'écris ces lignes, la démonstration ci-dessus se trouve sur un serveur Tomcat 4.0 en test à tecfa. Je prie par avance les lecteurs de bien vouloir m'excuser si cette démonstration ne fonctionne plus. Cependant, si vous voulez vraiment y accéder, faites le moi savoir et j'essaierai de la remettre en route dans les meilleurs délais.
Table des matières
Ces quelques exercices de programmation m'ont permis de m'initier au langage java. J'ai été plus particulièrement interessé par les applications côté serveur, notamment par les applications JSP qui sont d'un grande richesse et qui permettent de séparer clairement le travail des développeurs d'un côté et des graphistes/designers de l'autre.
C'est cette approche là qui m'a semblé la plus interessante et j'aimerais maintenant continuer à explorer cette technologie et construire avec une application un peu plus puissante afin de voir quelles en sont les limites.
Je pense pour cela:
Table des matières