Developpement de module : Etape 2
La préparation du développement
Une fois qu'un module est bien ce que l'on cherche à réaliser, et avant de commencer à ouvrir le capot, on peut commencer par une étude du "modèle propre" du module, c'est-à-dire, de sa modélisation fonctionnelle indépendante du contexte. Les méthodes sont multiples, mais le minimum à apporter est plus ou moins :
- un modèle de classes (objet) ou un modèle d'entités relationnelles (tables) dans lesquelles on installe systématiquement une clé primaire comme une colonne nommée 'id', de type entier plus ou moins grand selon l'entité de donnée. On peut commencer par des INT ce qui est une garantie de taille suffisante dans la plupart des cas, et on pourra réduire après. Le modèle de classes (de type UML) n'est là que pour donner également la structure des tables. On pourra le cas échéant faire des classes PHP avec, mais ce type d'applicatif ne tire pas un avantage faramineux de la programmation objet (on verra plus tard qu'on peut utiliser une technique "pseudo objet", dite "objets informels" ou "opportunistes" que PHP permet.
- des scénarios d'usage de ces données, basés au moins sur 2 rôles minimum :
- étudiant
- enseignant
C'est un modèle de départ très simpliste, auquel on ajoutera rapidement des altérations, par exemple lorsqu'il y a une stratégie de groupe. Le nouveau modèle de rôles apporte une richesse bien plus grande du modèle de développement, mais il peut être implémenté plus tard, une fois que le module prends corps. L'ensemble des scénarios et des utilisateurs sera implémenté sous forme de capacités.
- des scénarios d'écrans, dans lesquels "ce qu'on aimerait voir" est maquetté. De ce visuel (on appelle ça une démarche "user-driven").
Pour ce qui est des scénarios, il existe plusieurs cas de figure :
- Les modules à scénario séquentiel présentent un seul écran à la fois à l'utilisateur qui dépend de la phase de l'activité. Cette phase est gérée par rapport à un ensemble de champs datés dans l'enregistrement principal du module (discussion qui suivra sur le modèle de données d'un module). Exemple typique : Devoir (assignment)
- Les modules "pseudo-application" présentent une petite "web application" à l'intérieur du portail. On peut naviguer dans des écrans complexes via une barre d'onglets (super pratique à programmer, même pour une hiérarchie à deux ou trois niveaux -- discussion à suivre sur ce pattern). Exemple typique : les Tests, côté enseignant.
Il peut être enfin utile de préparer des maquettes HTML des formulaires simples, bien qu'il soit plus rentable de recopier des séquences déjà écrites dans d'autres modules (prochaine discussion pour vous dire dans quel fichiers trouver des séquences intéressantes).
