[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Dolibarr-dev] Utilisation de Dolibarr_print_error
From: |
Eldy |
Subject: |
Re: [Dolibarr-dev] Utilisation de Dolibarr_print_error |
Date: |
Tue, 14 Sep 2004 20:38:35 +0200 |
User-agent: |
Mozilla Thunderbird 0.7 (Windows/20040616) |
Rodolphe Quiedeville wrote:
Salut,
Je pense qu'il n'est pas bon d'utiliser dolibarr_print_error dans les
classes, serait-il possible de limiter cette utilisation dans sorties
ecrans uniquement, car quand on appelle des classes depuis un script
ce n'est pas très élégant cette sortie.
Ce point est appelé a être discuté.
A++
_______________________________________________
Dolibarr-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
La finalité présentie de dolibarr_print_error est d'afficher des infos
dans le cas d'une erreur technique grave qui n'est pas sensée arriver
(en général cela veut dire bug dans dolibarr, le plus souvent suite à
une requete mal générée à cause d'absence de controle des paramètres).
De part cette vocation, j'utilisais jusqu'ici la fonction à tous les
endroits du code (écran ou script) car quand cela arrive, le plus
souvent rien ne saire de continuer.
Une solution serait d'avoir 2 fonctions. Une pour les classes et une
pour les écrans mais cela complique le codage car en cas d'erreur sur la
fonction pour les classes en mode web, le retour (copie écran de
l'utilisateur qui a buggué) ne sera pas aussi complet ou ne pas la
mettre dans les classes, mais l'expérience à montré que les lacunes
étaient avant tout dans le code des classes car c'est lui qui génère les
requetes.
Aussi je propose une autre alternative: En cas d'appel depuis un script,
on pourrait détecter au sein de la fonction que l'on est en mode script
(La variable DOCUMENT_ROOT n'est alors pas définie) pour afficher un
affichage non web (avec de retours à la ligne de type \n plutot que < br
> et ne pas mettre les infos propres au web (comme l'url appelante), on
pourrait même y mettre des infos propres au script comme l'ID de process
et le PID. Cela permet d'avoir une fonction générique utilisable partout
avec un résultat élégant dans les 2 cas.
--
Laurent Destailleur.
---------------------------------------------------------------
EMail: address@hidden
AWStats : http://awstats.sourceforge.net
AWBot : http://awbot.sourceforge.net
CVSChangeLogBuilder : http://cvschangelogb.sourceforge.net