PROJET D’INTEGRATION

Point de départ et contraintes
- Réaliser un projet d’intégration

Objectifs

• Intégrer différentes techniques dans un ensemble
• Réaliser un projet d’une certaine complexité
• Connaître et savoir appliquer des moyens de protections d’une page ou d’un répertoire
• Maîtriser des requêtes SQL nécessaires pour la création de nouvelles données et la mise à jour
• Approfondir et perfectionner les connaissances PHP

Analyse des besoins

Le but a été le perfectionnement de l’application que j’ai créée lors de l’exercice 9 pour qu’elle soit utilisable. L’analyse a été faite sur la base du prototype existant. Les besoins suivants ont été détectés en vue du lancement d’une première version (release 1.0):

1. Création d’une section administration pour saisir et modifier des données directement via une interface web.
2. Protection pour la partie administration
3. Amélioration de l’ergonomie, en particulier la gestion des popups et de la présentation du contenu.
4. Développement des fonctionnalités supplémentaires
   
- Création d’un accès réservé aux membres
- Affichage d’un contenu individualisé
- Tribune pour s'exprimer et donner son opinion (commentaires, echhelle d'evaluation)
- Modification et suppression des commentaires

Design du dispositif
L’application a été construite avec PHP5 en combinaison d’une base de données MySQL et du Javas Script.
Les éléments ajoutés ont été réaliser de manière suivante:

1. Section administration
La page Admin permet soit la saisie de nouvelles données, soit la modification des données déjà existantes au travers de deux formulaires différents. Pour la modification, le choix peut se faire par titre de film. La requête sort toutes les colonnes du tableau principal et des tableaux liés.
Pour la saisie des nouvelles données, l’utilisateur doit entrer un minimum d’informations dans les champs obligatoires. Concernant les infos sur le réalisateur, la boîte de production et le genre qui se trouvent dans des tableaux séparés, l’utilisateur peut lier les données existantes ou en créer de nouvelles selon besoin.

2. Protection pour la partie administration
La section administration se trouve dans un répertoire qui a été protégé avec le fichier .htaccess. Cette solution me semblait la plus adaptée et plus sûre puisqu’il n’y avait pas de restrictions pour un groupe particulier.

3. Amélioration de l’ergonomie
Au niveau de l’ergonomie, de petites améliorations ont été apportées. P. ex., la taille des popups a été modifiée et adaptée à la taille du contenu. En outre, une solution Javas Script permet la fermeture automatique après l’entrée des données, une solution qui a posé des problèmes lors de la réalisation (voir commentaire).
Pour que l’utilisateur ait tout de suite une vue d’ensemble sur les nouveaux films à disposition sur le site, la page principale affiche les 16 derniers entrés sous forme de tumbnails. En cliquant sur un tumbnail, on accède aux détails du film.

4. Développement des fonctionnalités supplémentaires
L’accès au site nécessite dès lors un login qui a été réalisé avec l‘utilisation de la fonction start session(), la variable $_SESSION de PHP et un tableau login dans la base de données. Cette solution permet à l’utilisateur de se loger juste une fois par séance et que certaines données du login soient gardées et utilisables jusqu’à ce qu’il quitte le site.
En outre, l’identification de l’utilisateur permet de connaître son statut (actuellement, je différencie « membre » et « admin ») et de mieux gérer les restrictions au niveau des droits. P. ex., il sera possible que la personne qui a créé un commentaire puisse être la seule à le modifier et à le supprimer. (Malheureusement, je n'ai plus eu le temps de réaliser cette idée. Actuellement, tout le monde peut modifier et supprimer les commentaires sans restriction).
Une autre idée consiste en l'affichage d'un contenu individualisé en utilisant un cookie. Je voulais que l'utilisateur ne voie sur la page principale que les films nouveaux et ceux qu'il n'a pas encore vus. Cette idée est actuellement en chantier c'est-à-dire qu’il existe simplement un cookie qui compte les visites de l'utilisateur.

Commentaire sur la réalisation
J’ai repris l’exercice 9, mon projet préféré, pour optimiser la mise en oeuvre de mon idée de « jukeboxcinéma ».
La première tâche a consisté à construire une tribune où l’utilisateur puisse s’exprimer sur chaque film. Cette idée était déjà esquissée dans la version précédente. Pour la perfectionner, j’ai donc ajouté une échelle pour évaluer les films et une fonctionnalité pour modifier et supprimer les commentaires.
La programmation de cette fonctionnalité supplémentaire n’a pas posé trop de problèmes, mais pendant la phase de test, j’ai observé un phénomène qui m’a semblé totalement bizarre et atypique dans l’informatique: la suppression ou la modification des commentaires fonctionnait une fois sur trois, sinon rien ne se passait dans la base de données sans que je n’aie aucun message d’erreur .
Pour trouver l’erreur, j’ai isolé du code bout par bout sans que ce debougage n’apporte une réponse nette au problème. Bien au contraire, tous ces tests ont affirmé que le code était correct. J’étais un peu perplexe . Normalement cela marche ou cela ne marche pas et il n'existe pas de vérité entre ces deux pôles.
Aussi, j’ai testé la page suspecte sur d’autres ordinateurs pour exclure d’éventuels problèmes de réseau ou de connexion, mais sans succès.
Pour ne pas complètement bloquer le projet, j’ai commencé à travailler sur le perfectionnement d’autres fonctionnalités. Du coup, en modifiant le code Javas Script j’ai eu un soupçon: l’erreur devait venir d’une fonction Javas Script qui exécute la fermeture de la fenêtre après que l’utilisateur a cliqué sur les boutons « modifier » ou « supprimer ». Après avoir masqué le code en question, j’ai eu la certitude que mon soupçon était juste.
L’exécution de la fonction Javas Script qui se trouvait tout en haut de la page était parfois plus rapide que l’exécution du script PHP qui se trouvait en bas de page.
La fermeture de la fenêtre tuait la lecture du code !
La prochaine question ouverte que je voulais encore aborder était la problématique autour de la sécurité. J’ai repéré deux solutions qui m’intéressent : .htaccess une solution avec deux fichiers qui marche sur les serveurs Apache et une identification via base de données et session.
.htaccess me semblait plus simple, mais je ne savais pas comment créer et placer le fichier .htpasswd dans un répertoire sur un serveur via mon terminal.
Comme je trouvais un exemple sur l’identification via sessions, j’ai attaqué cette solution en premier. Sa réalisation m’a permis de m’apercevoir sur le principe de sessions qui m’inspiraient pour d’autres idées que je devrais réaliser pour les prochaines releases.
La programmation de la section Admin n’a pas été très compliquée, mais le code qui commençait à s’étaler sur plusieurs centaines de lignes n’était pas toujours simple à gérer et m’a poussée plusieurs fois au bord de la crise de nerf. L’oubli d’un simple signe était infernal et la recherche de fautes énervante. Dans ce contexte, l'application d'une bonne technique de debougage est importante, ce que je devrais encore améliorer. Pour ne pas trop me perdre dans cette jungle de codes, j’ai simplifié la page Admin et laissé tomber quelques idées de départ. Sans mettre des commentaires partout, je n’en saurais jamais sortie.
En regardant le code de mes pages, je me suis aperçue que j’aurais pu faire plus simple en utilisant des fonctions. Mais à la fin, j’étais tellement contente que ce projet marche enfin sans erreur et selon mes intentions que je n’ai plus eu envie de toucher quoi que ce soit, sachant que l’utilisateur ne saurait jamais comment cela avait été fait. Ce qui l’intéresse, c’est ce qu’il peut voir sur l’écran. Et cela doit :a) fonctionner, b) plaire et c) faire plaisir.
Comme une voiture, une montre - ou un amant.