Le codage

Maintenant que nous avons nos outils, il est temps de nous mettre au codage. Là encore, le scénario proposé est le fruit de mes années de développement.

Jusqu'à présent, nous avons identifié les différents cas d'utilisation à coder. Dans l'étape précédente, nous avons défini, puis installé (là, je n'ai pas décrit...), les outils dont nous avons besoin. Le serveur web est opérationnel, la base de données, bien que vide pour le moment, est créée.

Le premier cas d'utilisation à coder est sur la table. La première étape consiste à le découper en modules.

Découper un cas d'utilisation en modules

Voici une vision synthétique de l'ensemble des opérations à réaliser pour :

• afficher une liste en fonction de critères de sélection ;
• afficher les détails d'une fiche ;
• la modifier ;
• revenir à la liste.

Dans cet exemple, le module affiche d'abord une boite permettant de sélectionner des critères de recherche, puis la liste des personnes correspondantes. La sélection d'une fiche permet d'accéder à son détail, puis de passer en modification. Après modification, on retourne aux critères de recherche.

Pour bien comprendre le fonctionnement, voici un diagramme de séquence qui s'intéresse uniquement à l'affichage de la liste, à partir des critères de recherche préalablement définis. Les critères de recherche sont stockés dans une classe.

Dans cet exemple, le module récupère la liste des critères de recherche, qu'il transmet à la classe Personne. Celle-ci prépare une requête SQL. Les données récupérées sont ensuite transmises à la classe chargée de l'affichage.

Une fois toutes les données transmises, le module déclenche l'affichage de la page web.

Vous pouvez utiliser le même principe pour quasiment toutes les modules.

Ainsi, pour notre cas d'utilisation « saisir une fiche », nous avons au minimum les modules suivants :

• sélection des critères ;
• affichage de la liste (qui peut être intégré au module précédent) ;
• affichage du détail d'une fiche ;
• affichage du formulaire de modification ;
• enregistrement des modifications ;
• et je rajouterai, pour des questions de droits d'accès, un module de suppression d'une fiche.

Il y a quelques années, je regroupais plusieurs modules en un seul : affichage du formulaire, enregistrement des modifications, et suppression. J'ai arrêté, et suis revenu à une segmentation plus fine. En effet, même si ce n'est pas forcément évident quand on commence le codage, les droits attribués sont différents selon ce qu'on veut faire :

• droit de consultation ;
• droit de modification simple ;
• droit de suppression.

Si vous regroupez tout en un seul module, la gestion des droits va devenir très complexe, et vous aurez du mal à vous intégrer totalement dans votre framework.

Les classes

De quelles classes avons-nous besoin ? Dans l'exemple précédent, on peut mettre en évidence deux classes propres à l'application :

• la classe contenant les critères de recherche. En général, je la stocke en variable de session, ce qui me permet de récupérer les critères de sélection quand l'utilisateur retourne à l'affichage de la liste ;
• la classe qui permet de générer automatiquement le code SQL pour retrouver les informations depuis la base de données. En général, cette classe est héritée d'une classe parent, qui contient déjà le code adéquat pour générer les requêtes SQL.

Le schéma ci-dessus présente quelques classes fournies par le framework PrototypePHP (http://prototypephp.sourceforge.net/) :ObjetBDD, qui s'appuie sur ADODB pour l'accès à la base de données. ObjetBDD est hérité en Personne.

Il n'est pas obligatoire de créer une classe par table de la base de données. On le fait en général pour les tables porteuses d'informations spécifiques, mais ce n'est pas forcément pertinent pour les tables porteuses de relations N-N : elles peuvent parfaitement être traitées par la table principale qui les gère (vous pouvez consulter à ce sujet cet article : http://www.linux-professionnel.net/programmation/base-de-donnees-objet-et-acces-aux-tables ; il ne répond pas tout à fait à cette problématique, mais n'en est pas très éloigné).

En gros, ne confondez pas base de données et modèle objet : même si, au niveau des schémas, ils peuvent se ressembler, dans la pratique, ils fonctionnent différemment.

L'ergonomie générale de l'application

Avant toute chose, je vous conseille la lecture du livre blanc édité par SMILE : http://www.smile.fr/Livres-blancs/Culture-du-web/Conceptions-d-applications-web. Vous y trouverez de nombreux conseils pertinents.

L'ergonomie d'une application de gestion n'est pas forcément aussi sensible qu'un site marchand. Néanmoins, le respect de certaines règles va permettre à vos utilisateurs de s'y retrouver rapidement, et de savoir l'utiliser avec un minimum de formation.

À contrario, une application « mal fichue » va être difficile à appréhender, et nécessitera une formation particulière, ne serait-ce que pour comprendre comment elle fonctionne. J'ai eu, à ce sujet, une expérience assez désastreuse. Un nouveau logiciel est en cours de déploiement au sein de certaines administrations publiques. Le programme a été construit en recourant à du Javascript, très probablement à partir d'un atelier logiciel probablement performant. Mais l'ergonomie retenue est incompréhensible : en tant qu'informaticien, je n'ai pas été capable d'arriver à la faire fonctionner sans qu'on m'explique comment il fallait l'utiliser ! Imaginez ceux qui n'ont pas l'habitude de manipuler l'outil informatique...

Quelques conseils d'ergonomie

D'une manière générale, il vaut mieux conserver l'ergonomie générale du web et éviter de copier l'interface Windows. Cela peut se traduire ainsi :

• une page web est toujours déconnectée, peut être abandonnée, ou on peut y accéder par l'intermédiaire d'un raccourci. Cela implique que les informations qui sont saisies doivent être conservées, quel que soit le contexte, et notamment lorsque la saisie impose de nombreuses pages successives. De même, il est impossible de prévoir à l'avance par où va passer l'utilisateur pour accéder à une information ;
• l'ergonomie générale doit être de la forme : critères de sélection, liste de résultats, accès au détail, modification, suppression, ou rajout d'un élément ;
• privilégiez le mode « chemin de fer » quand c'est possible, c'est à dire une présentation qui serait de la forme :

Critères > liste > détail fiche > modification

• ce qui permet à l'utilisateur de savoir où il se trouve, et de revenir facilement à une situation antérieure.
• Utilisez de préférence les formulaires en mode « GET », pour que la fonctionnalité RETOUR du navigateur puisse fonctionner. Ne réservez le mode « POST » que pour les enregistrements de fiches, et dès lors que le retour arrière peut avoir des répercussions gênantes dans l'application ;
• ne multipliez pas les fenêtres : au pire, utilisez des fenêtres popup pour sélectionner des informations particulières concernant la fiche principale. Seule exception : les pages d'aide, qui ont tout intérêt à être séparées de l'application ;
• en mode saisie, pensez que l'utilisateur va manipuler son clavier : complétez les listes déroulantes avec des saisies au clavier, plus rapides... Ainsi, plutôt que de chercher dans une liste déroulante une commune, autant pouvoir la saisir au clavier, et l'associer ensuite à la fiche correspondante dans la base de données ;
• Une page, une information...
• utilisez tout l'écran : ne mettez pas de marge à gauche ou à droite. Si l'utilisateur dispose d'un grand écran, il ne pourra pas l'utiliser, ce qui serait dommage...
• si le scrolling vertical est un grand classique, l’ascenseur horizontal est à bannir.
• Préférez les liens aux boutons : leur symbolique peut échapper à l'utilisateur occasionnel.
• Pour les saisies de dates, utilisez une zone de texte couplée à un calendrier. Ne découpez pas la date en trois zones, c'est une catastrophe d'un point de vue ergonomique, même si certains outils, comme Smarty, le propose.
• Pour les saisies multiples (plusieurs lignes rattachées à un dossier), soit vous réalisez la saisie dans une page dédiée, soit vous utilisez un formulaire situé sous la liste, à condition qu'il n'y ait pas trop d'informations à saisir.
• Évitez d'utiliser trop de Javascript : conservez simplement le code utile, évitez les fioritures.
• Conservez les liens hypertextes soulignés, avec le code couleur par défaut bleu/violet (ou noir/gris) : l'utilisateur ne sera pas dérouté, et pourra identifier immédiatement les liens dans la page ;
• ne touchez pas aux tailles de caractères (sauf cas particulier, comme le pied de page, par exemple). L'utilisateur doit pouvoir augmenter ou diminuer la taille d'affichage, en fonction de son poste de travail, de sa vue, …
• si vous utilisez des onglets, considérez que les onglets correspondent à une page web indépendante. Ne gérez pas les onglets dans une seule page, qui contiendrait tout le contenu du dossier (code DHTML). Chaque onglet doit pouvoir être enregistré de façon indépendante. L'utilisateur doit également savoir qu'il doit enregistrer chaque onglet, avant de passer au suivant (bouton « enregistrer ») ;
• Si vous le pouvez, utilisez un graphiste web pour vous aider à générer votre modèle d'application : les bons développeurs ne sont pas forcément des bons graphistes...

On pourrait continuer longtemps mais, pour résumer : faites simple, évitez les fioritures ou les « astuces », mettez vous à la place de l'utilisateur. Pensez également que tout ce qui est complexe à écrire est complexe à maintenir.

Le javascript

Avec l'arrivée de navigateurs compatibles HTML5, le javascript a pris de l'ampleur, et est de plus en plus associé aux pages web. Mais, là encore, utilisez-le à bon escient, quand il apporte vraiment quelque chose. N'oubliez-pas que si vous intégrez du javascript spécifique dans une page, la maintenance en sera plus complexe.

J'utilise actuellement le javascript pour :

• mettre à jour des listes de sélection (boites dropdown) : l'utilisateur tape quelques caractères dans une zone de texte, et la sélection se met à jour par l'intermédiaire de requêtes Ajax ;
• identifier les zones de saisie obligatoires qui sont vides, avant de les envoyer au serveur. Ce contrôle doit, de toute façon, être réalisé également côté serveur, vous ne maîtrisez pas le poste client ;
• quelques aides à la saisie ou à la navigation : contrôles « calendrier », affichage d'informations au survol, etc.

Pour de plus amples informations sur ce que j'ai mis en place, je vous invite à consulter la page suivante : http://www.linux-professionnel.net/programmation/integrer-html-javascript-et-css-dans-une-application-php.

N'hésitez pas à utiliser des bibliothèques Javascript, qui vous éviteront de tout avoir à réécrire. JQUERY (http://jquery.com/) dispose de nombreux modules faciles à rajouter, et est particulièrement riche. Il existe également le couple Prototype/script.aculos.us (http://prototypejs.org/, http://script.aculo.us/) qui est aussi très réputé. Ces deux bibliothèques fonctionnent différemment mais, là encore, c'est une affaire de goût... et de mode.