dolibarr-dev
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]