" Saviez-vous que le traitement des erreurs dans les formulaires était la raison principale du développement de Javascript?"
p. 46 (HTML: niveau 2, 2000)
Ce rapport résume l'évolution de mon travail fournit pour le cours staf 14 lors de la troisième période. Il
comprend la réalisation d'une séance de voyance, réalisée grâce à Javascript. Le traitement du formulaire se faisant à partir d'un fichier PHP (Hypertext Preprocessor), que j'ai essayé d'améliorer par rapport à celui crée pour l'exercice 2 (sutout au niveau de la vérification des champs lors de la saisie). Les commentaires sur l'évolution de ma démarche se feront selon les 3 points habituels: objectifs & implémentation, difficultés rencontrées et réflexions & références:
objectifs & implémentation - malgré ma première introduction à javascript lors de la réalisation de ma homepage (j'avais utilisé un open.windowopen.window pour faire apparaître une fenêtre), mon objectif était avant tout d'approfondir mes connaissances en Javascript. Mon objectif premier était d'utiliser un maximum d'événements disponibles en js (onLoad, onMouseOver, onMouseOut, onClick, onReset, onSubmit, etc.), ainsi que d'améliorer la récupération des données en PHP. Pour ça, j'ai imaginé une séance de voyance qui pousserait l'utilisateur à remplir un formulaire administratif en HTML. Et c'est à ce niveau que j'ai pu tester l'intérêt d'une vérification des champs au moment de la saisie des données. Au départ, j'avais intégré dans la même page du javascript et du php, mais la priorité était donné à PHP. Du coup, la vérification des champs que j'avais associé au bouton SUBMIT ne marchait pas. J'ai donc contourné le problème en intégrant la vérification des champs dans la page PHP (si l'un des champs n'est pas rempli, la page affiche un message d'erreur en HTML avec un lien retour au formulaire. Si les champs sont correctement remplis, le feedback est affiché et la séance peut débuter). Le problème, c'est que lorsque l'utilisateur revient au formulaire parce qu'il a fait une erreur, la page se recharge sans garder en mémoire les données qu'il avait déjà entrées. L'idéal aurait été de créer une fonction afficher () dans la page de formulaire, fonction à laquelle aurait été associée un calcul spécifique pour chaque variable (nom, prenom, adresse, etc.). Si le résultat est égal à zéro, la fonction affiche le feedback en PHP. Sinon, on reviendrait au formulaire mal rempli avec une alert box spécifique à l'erreur ("Le champs 'adresse' est resté vide, veuillez le remplir pour passer à la suite!..."). Le but ultime est donc de vérifier l'exactitude des données, avant la récupération de celles-ci sur le serveur. La question est donc de savoir comment intégrer du PHP dans une page réalisée avec du javascript. De manière générale, mon objectif premier est atteint puisque j'ai pu réaliser un questionnaire plus performant que dans l'exercice 2. De plus, j'ai pu faire le constat de la relative inutilité de javascript, si ce n'est ce à quoi il était initialement destiné: la vérification des données d'un formulaire.
difficultés rencontrées - dans l'ensemble, je n'ai pas eu de grandes difficultés à comprendre le fonctionnement de javascript. Maintenant, il est vrai que je me suis casser les dents au moment de l'intégration de PHP à javascript, car au départ je ne comprenais pas pourquoi le browser donnait toujours la priorité à PHP, plutôt que de considérer d'abord la vérification des données liée au bouton SUBMIT. Puis à force de rester bloqué, j'ai contourné le problème en intégrant la vérification du formulaire au sein du fichier .php. Ce n'est peut-être pas très élégant, mais ça m'a au moins permis de prendre conscience que cette solution n'était toujours pas la plus pratique. Mais existe-t-il vraiment une possibilité? La deuxième difficulté majeure se situe au niveau de la procédure permettant d'afficher du texte dans un textarea, grâce à javascript. J'ai passé du temps à bidouiller le code source, car j'avais fait l'erreur de donner le même nom (Q1) à la fois au menu déroulant et au textarea. Du coup, lorsque je définissais le lieu où le texte devait apparaître (onClick=" forme.Q1.value='...), le browser ne pouvait pas faire la différence entre le menu et le textarea. Il a suffit de mofifier le nom du textarea (R1), pour que tout tourne comme il faut. Cependant, l'évènement onClick associé à un textarea ne fonctionne que sur Netscape6, c'est donc pour cette raison que j'ai prévu un alertbox dès le chargement de la première page pour prévenir l'utilisateur que la séance n'aura lieu que sur la dernière version de Netscape.
réflexions & références - sur le plan technique, j'ai essayé de prendre en considération les remarques que D. Schneider m'avait fait lors du dernier exercice. C'est pour cette raison que j'ai appris à vérifier si mon code source est correctement écrit (via XEmacs: DTD > parse DTD / MOVE > next trouble spot / via le browser: HTML Validation Service). De plus, j'ai compris l'intérêt de commenter systématiquement toutes les points importants de l'écriture du fichier, ce qui m'a permis de voir que les commentaires ne s'inséraient pas de la même manière selon que l'on se trouve dans des balises PHP ou HTML. J'ai également pu profiter de vérifier l'exactitude du javascript grâce au débogueur (javascript: dans le browser). Sur le plan conceptuel, mon objectif premier était de montrer à la fois les aspects positifs (vérification des champs d'un formulaire) et négatifs (abus dans l'utilisation des alertbox, limites au niveau des browsers, longueur du code source, etc.) de javascript. Pour y arriver, je me suis inspiré d'un test de personnalité qui se base sur les cartes du tarot. En fait, c'est parti d'un challenge que je me suis lancé. L'idée était d'essayer de transposer un test de personnalité que j'avais sur un support papier en une séance de voyance en format HTML, tout en essayant de le faire avec javascript. De plus, j'avais comme idée de reprendre le formulaire que j'avais développé dans l'exercice 2, pour pouvoir y rajouter une meilleure vérification des données (car j'ai l'intention de réutiliser ce type de formulaire dans la création de sites éducatifs). l'idée était donc d'insister sur la continuité des acquis d'une période à l'autre. Enfin, j'ai continué à garder à l'esprit la notion de usability, en faisant des pages pas trop remplies même si le choix du thème m'a forcé à inclure pas mal d'images. Précisons encore, pour ceux qui n'avaient pas compris, que la voyance est vraiment le dernier de mes soucis. Ce choix n'est pas celui d'un passioné, ni même d'un amateur!