Merci pour ces explications, Chicha, je pense que je commence à mieux cerner
ce que tu veux faire :-)
> Dans ce que tu dis et avec les exemples que tu donnes il y a en fait 2
> problemes
> amha :
>
> 1- Le contenu des messages : ce qu'il signifie, l'importance qu'il a a
> nos yeux
> et a ceux de l'utilisateur...
>
> 2- Le sequencement de Ncooker : plusieurs etapes s'enchaines les unes
> apres les
> autres. Certaines sont tantot etape principale, tantot etape secondaire...
> Chaque etape contient des messages. Ce n'est pas parce qu'un message est de
> niveau DETAIL dans une etape secondaire (secondaire dans un use case
> precis) qu'il devient INFO lorsque la meme etape est primaire (primaire
> dans un use case precis). Qu'il soit dans une etape primaire, secondaire ou
> tertiaire, du detail reste du detail. Ca vaut pour tous les niveaux.
Ok, je comprends mieux :-) J'ai tout de même quelques doutes sur le fait qu'un
message de niveau DETAIL reste toujours de niveau DETAIL quelle que soit le
positionnement de l'étape. J'aurais quand même tendance à penser que ça
dépend du contexte d'utilisation.
Par exemple, si « Ncooker -v INFO pack » m'affiche :
Creation of the working_dir package ...
Checking working_dir directory content ... [ OK ] <- affiché par Check
Preparing packaging environment ... [ OK ]
Create "working_dir" NBUILD package ... [ OK ]
Cleaning packaging environment ... [ OK ]
Cela signifie que le seul message de niveau INFO de la commande Check est
celui que j'ai annoté. Dans le contexte d'utilisation de la commande Pack, ça
me convient parfaitement, et les messages affichés me paraissent adaptés pour
le niveau INFO. Mais si je lance « Ncooker -v INFO check », il va m'afficher
uniquement :
Checking working_dir directory content ... [ OK ]
Il n'y aura pas ces messages :
Checking "infos" file ...
Checking "build" file ...
Checking "desc" file ...
Checking "changelog" file ...
qui ne me paraisse pourtant pas être du « détail » dans ce nouveau contexte où
je cherche à vérifier la validité de mon paquet. J'aimerai savoir directement
si un fichier contient une erreur ou non. Si c'est le cas, je sélectionnerai
alors le niveau DETAIL pour savoir précisément quel est l'élément fautif du
dit fichier.
Le problème de tout ceci est que c'est très subjectif, et que la perception de
ce qui relève de l'ordre du détail ou non peut grandement varier d'un
utilisateur à l'autre :-) .
Un autre inconvénient de cette approche, et que le développeur qui veut créer
une nouveau module doit essayer de trouver à quel niveau il doit commencer
l'affichage de ces messages pour qu'ils s'adaptent au mieux aux
commandes/modules qui vont l'utiliser.
Pour le développement d'une commande, la question ne se pose pas : comme elle
peut être appelée directement en ligne de commande, il faut commencer au
niveau INFO.
Mais pour les modules, comment savoir ? Sachant qu'ils sont obligatoirement
appelés par une commande ou un autre module, doivent-ils commencer au niveau
INFO, DETAIL ou FULL ? Commencer au niveau DETAIL pourrait convenir
lorsqu'ils sont utilisés par une commande, mais comment garantir que ça
conviendra lorsqu'ils seront utilisés par un autre module ?
Maintenant, imaginons que pour une raison X ou Y, le développeur d'un module
passe tous ces messages de DETAIL à FULL (ou inversement). Comment être sûr
que les informations affichées vont rester cohérentes ?
Je pense que faire en sorte que chaque commande/module commence son affichage
à partir du niveau INFO, et que le gestionnaire de messages se débrouille
pour réaliser les décalages de niveau nécessaires simplifierait grandement la
vie des développeurs. :-)
> Je vois clairement ce qu'ERROR, WARNING, INFO, DETAIL et FULL veulent dire,
> et je m'imagine tres bien l'expliquer dans un manuel.
> je ne vois pas du tout la difference entre un niveau 1,2 ou 3.
> Pour moi il y a un niveau de detail au dela du quel ca ne sert a rien de
> detailler un peu plus : on affiche tout ce qui arrive. C'est la
> signification de FULL par rapport a DETAIL.
Oui, c'est une distinction qui peut se voir de cette manière :-)
Si je comprends bien, ce qui te gène à ce niveau, c'est le fait que 1, 2 ou 3
soit moins parlant que INFO, DETAIL ou FULL. Pourquoi ne pas faire un mix de
nos deux solutions alors ?
- On garde INFO, DETAIL et FULL (avec FULL : affichage de tout ce qui arrive)
- Chaque commande/module commence l'affichage de ces messages avec le niveau
INFO (pour simplifier la vie des développeurs)
- On utilise les fonctions shiftMsgLevel() et unshiftMsgLevel() pour décaler
le niveau des messages des commandes/modules appelés. Si un message décalé
dépasse le niveau FULL, il reste forcé à FULL. Ainsi, il seront tous affichés
si le niveau FULL est sélectionné
késtenpense ? :o)=)
++
Gontran
