• Aucun résultat trouvé

6.Etude de cas Gestion d'une base d'articles sur le web

Objectifs :

 écrire une classe de gestion d'une base de données d'articles  écrire une application web s'appuyant sur cette classe  introduire les feuilles de style

 proposer un début de méthodologie de développement pour des applications web simples  introduire javascript dans le navigateur client

Crédits : L'essence de cette étude de cas a été trouvée dans le livre "Les cahiers du programmeur - PHP/MySQL" de Jean-Philippe Leboeuf aux éditions Eyrolles.

6.1Introduction

Un commerçant désire gérer les articles qu'il vend en magasin. Il a déjà chez lui une application ACCESS qui fait ce travail mais il est tenté par l'aventure du web. Il a un compte chez un fournisseur d'accès internet, fournisseur autorisant ses clients à installer des scripts PHP dans leurs dossiers personnels. Ceci leur permet de créer des sites web dynamiques. Par ailleurs, ces mêmes clients disposent d'un compte MySQL leur permettant de créer des tables pouvant servir des données à leurs scripts PHP. Ainsi le commerçant a un compte MySQL ayant pour login admarticles et mot de passe mdparticles. Il possède une base dbarticles sur laquelle il a tous les droits. Notre commerçant a donc les éléments suffisants pour mettre sa gestion d'articles sur le web. Aidé par vous qui avez des compétences dans le développement Web, il se lance dans l'aventure.

6.2La base des données

Notre commerçant fait la maquette suivante de l'interface web d'accueil qu'il souhaiterait :

Il y aurait deux sortes d'utilisateurs :

des administrateurs qui pourraient tout faire sur la table des articles (ajouter, modifier, supprimer, consulter, ...). Ceux-là pourront utiliser tous les éléments du menu ci-dessus. En particulier, ils pourront émettre toute requête SQL via l'option [Requête SQL].

les utilisateurs normaux (pas administrateurs) qui auraient des droits restreints : droits d'ajouter, de modifier, de supprimer, de consulter. Ils peuvent n'avoir que certains de ces droits, le seul droit de consultation par exemple.

Du fait qu'il y a divers types d'utilisateurs de la base n'ayant pas les mêmes droits, il y a nécessité d'une authentification. C'est pourquoi la page d'accueil commence avec celle-ci. Pour savoir qui est qui, et qui a le droit de faire quoi, deux tables USERS et DROITS seront utilisées. La table USERS aurait la structure suivante :

login login de l'utilisateur l'identifiant de façon unique. Ce champ est clé primaire de la table. mdp le mot de passe en clair de l'utilisateur

admin le caractère 'y' (yes) si l'utilisateur est administrateur, sinon le caractère 'n' (no).

Le contenu de la table pourrait être le suivant :

La table DROITS précise les droits qu'ont les utilisateurs non administrateurs présents dans la table USERS. Sa structure est la suivante :

login login de l'utilisateur l'identifiant de façon unique. Ce champ est clé étrangère de la table DROITS et référence la colonne login de la table USERS.

table le nom de la table sur laquelle l'utilisateur a des droits.

ajouter le caractère 'y' (yes) si l'utilisateur a un droit d'ajout sur la table, sinon le caractère 'n' (no). modifier droit de modifier : 'y' ou 'n'

supprimer droit de supprimer : 'y' ou 'n' consulter droit de consulter : 'y' ou 'n'

Le contenu de la table pourrait être le suivant :

Remarques :

 Un utilisateur U se trouvant dans la table USERS et absent de la table DROITS n'a aucun droit.

 Dans notre exemple, les utilisateurs n'auront accès qu'à une seule table, la table ARTICLES. Mais notre commerçant, prévoyant, a néanmoins ajouté le champ table à la structure de la table DROITS afin de se donner la possibilité d'ajouter ultérieurement de nouvelles tables à son application.

 Pourquoi gérer des droits dans nos propres tables alors qu'on fait l'hypothèse qu'on utilisera une base MySQL capable elle- même (et mieux que nous) de gérer ces droits dans ses propres tables ? Simplement parce que notre commerçant n'a pas les droits d'administration sur la base MySQL qui lui permettraient de créer des utilisateurs et de leur donner des droits. N'oublions pas en effet que la base MySQL est hébergée chez un fournisseur d'accès et que le commerçant n'est qu'un simple utilisateur de celle-ci sans aucun droit d'administration (heureusement). Il possède cependant tous les droits sur une base appelée dbarticles à laquelle il accède pour le moment avec le login admarticles et le mot de passe mdparticles. C'est dans cette base que prennent place toutes les tables de l'application.

La table ARTICLES rassemble les informations sur les articles vendus par le commerçant. Sa structure est la suivante : code code de l'article - clé primaire de la table - 4 caractères exactement nom nom de l'article

prix son prix

stockActuel le niveau actuel de son stock

stockMinimum le niveau au-dessous duquel, une commande de réapprovisionnement doit être faite

Son contenu utilisé dans un premier temps comme test pourrait être le suivant :

6.3Les contraintes du projet

Le commerçant migre ici une application ACCESS locale en une application Web. Il ne sait ce que deviendra celle-ci et comment elle évoluera. Il voudrait cependant que la nouvelle application soit facile à utiliser et évolutive. C'est pour cette raison que son conseiller informatique a imaginé pour lui, lors de la conception des tables, qu'il pouvait y avoir :

 divers utilisateurs avec différents droits : cela permettra au commerçant de déléguer certaines tâches à d'autres personnes sans pour autant leur donner des droits d'administration

 dans le futur d'autres tables que la table ARTICLES Le même conseiller fait d'autres propositions :

 il sait que dans le développement logiciel, il faut séparer nettement les couches présentation et les couches traitement. L'architecture d'une application web est souvent la suivante :

L'interface utilisateur est ici un navigateur web mais cela pourrait être également une application