Les états
Je ne connais pas un développeur qui aime faire des états !
Je ne connais pas un générateur d'états qui fasse exactement ce qu'on souhaite !
Les problèmatiques sont les suivantes :
- Les ruptures et totaux : ça tombe en général n'importe où.
- La place sur l'état : soit on imprime presque rien et le client se plaint, soit on gâve la page et c'est illisible, soit on espace bien les informations et les gens disent qu'on gâche du papier, soit on réduit la taille de la police et c'est encore plus illisible !
Mis à part de simples listes avec 3 ou 4 rubriques on se retrouve souvent à concevoir des usines à gaz en jouant comme on peut avec les possibilités et les failles de l'éditeur. Alors on obtient un "machin" difficile à maintenir avec du code éparpillé un peu partout, le code métier se retrouvant mélangé avec le code technique.
Ma manière d'aborder les choses :
Ca fait pas mal d'années que j'ai décidé de traiter un maximum de choses en amont de l'état, c'est à dire de lui fournir un (des) fichier(s) temporaire(s) et qu'il ait un minimum à faire ! Toute la gestion se fait dans des algorithmes métiers bien isolés.
Les avantages sont les suivants :
- Code métier clair et facilement maintenable.
- Possibilité de contrôler les ruptures d'une manière très souple.
- Possibilité de gérer des choses difficiles à faire dans un état : par exemple imprimer les totaux en début de bloc.
- L'état n'est plus qu'un "agent" qui exécute bêtement ce que lui demandent les fichiers transmis : uniquement du code technique.
- Contrôle de l'état d'avancement avec une jauge par exemple : l'essentiel du temps passé se fait dans l'algorithme et non dans l'état.
Il est également possible de passer par des structures mais je n'ai pas suffisamment pratiqué. Le principe reste néanmoins le même.
Mise en oeuvre :
J'ai pour habitude de créer dans mes applis plusieurs fichiers génériques contenant un certain nombre de rubriques standards, par exemple TEXTE1, TEXTE2, etc... TEXTELONG1, TEXTELONG2, etc...NUMERIQUE1, NUMERIQUE2, etc...
Je ne m'encombre pas de X types de rubriques différents, le type numérique étant un réel, ce qui permet de stocker tout type de valeur numérique. De même pour les rubriques apparentées au texte (date, heure ...) je les stocke dans des rubriques texte. De toute manière ces rubriques seront formatées de manière adéquate dans l'état. Je prévois également quelques zones de texte long de plus de 200 caractères pour des zones commentaires.
J'ajoute aussi quelques zones textes qui seront des clés. Au développeur de les remplir "à la main" : CLE1, CLE2, etc... Ces clés serviront pour le parcours et pour les ruptures.
Ces fichiers sont de type HyperFile Classic. Ils seront crées dans le dossier temporaire de l'application lors de chaque lancement d'état. Bien entendu ce dossier temporaire doit être sur le poste de travail sans quoi ça peut être la fiesta !
Pour des états sous WebDev il est possible de créer des sous-dossier sur le serveur avec par exemple l'adresse IP de chaque machine ou bien le nom d'utilisateur s'il est géré.
Un exemple :
On veut la liste des factures par client à partir d'une certaine date avec une rupture par client et un total par client.
Ce type d'état est facilement réalisable avec l'éditeur d'état WD.
J'ai créé une requête WD retournant une ligne par facture (fichier FACTURE) avec en plus le nom du client qui se trouve dans le fichier CLIENT.
Un paramètre transmis à la requête me permet de ne sélectionner que les factures supérieures à une date :
Voici la description de l'état WD avec une rupture : dans le haut de la rupture on imprime le nom du client et dans le bas on imprime une zone calculée cumulant les montants de factures pour chaque client.
Et voici le résultat en exécution :
Voici donc un état parfaitement conforme à ce que sait faire l'éditeur Windev. Il n'y a d'ailleurs aucune ligne de code.
Maintenant on va corser un peu le problème ...
Suite dans le prochain article.