par
devlop78 » 23 mars 2011, 19:56
Tu fais un alert(), lol ...
De toutes façons, Il faut bien que PHP puisse dire à JavaScript qu'il y a eu une erreur et que la valeur qu'il retourne n'est pas correct. Des fois, retourner NULL ne sera pas bon. tu peux donc imaginer discuter avec JavaScript en JSON, en lui envoyant plusieurs choses : un code erreur/succès, éventuellement un message erreur/succès, et les données vraiment utiles. Derrière ça, tu crées une classe qui va extraire ces données, et par exemple emettre une exception s'il trouve une erreur, etc ... En plus, si jamais ta page emet une FATAL ERROR, tu vas te retrouver avec des données corrompus. Si tu utilises JSON, le Fatal ERROR va empêcher le parsage du JSON, et tu pourras le gérer. tu peux donc aussi tout simplement faire : Code bien executé = on envoit un JSON, code mal executé = on envoie autre chose. A priori, même une valeur de retour vide peut cacher une erreur. Il faudrait donc la traiter tel quel, et ne considérer qu'une valeur n'est bonne que si elle respecte un format particulier. Arprès, envoyer des messages simples à javascript, ne révélant aucun fichier, etc, pour effectuer une alert() dans le cadre d'un débogage, et désactiver le alert() en production. S'il y a une erreur, le méchant qui voudrait lire le message se trouvera en face d'un message dont il ne peut rien faire. On peut aussi détecter l'adresse IP en php, et envoyer un message d'erreur si en débogage, et ne rien envoyer en production (mais ce sera considéré quand même comme une erreur ... et alors JavaScript pourra dire au client "Nous sommes désolés, une erreur inconnue a eue lieu"). bref, tout est possible, tout est imaginable

Tu fais un alert(), lol ...
De toutes façons, Il faut bien que PHP puisse dire à JavaScript qu'il y a eu une erreur et que la valeur qu'il retourne n'est pas correct. Des fois, retourner NULL ne sera pas bon. tu peux donc imaginer discuter avec JavaScript en JSON, en lui envoyant plusieurs choses : un code erreur/succès, éventuellement un message erreur/succès, et les données vraiment utiles. Derrière ça, tu crées une classe qui va extraire ces données, et par exemple emettre une exception s'il trouve une erreur, etc ... En plus, si jamais ta page emet une FATAL ERROR, tu vas te retrouver avec des données corrompus. Si tu utilises JSON, le Fatal ERROR va empêcher le parsage du JSON, et tu pourras le gérer. tu peux donc aussi tout simplement faire : Code bien executé = on envoit un JSON, code mal executé = on envoie autre chose. A priori, même une valeur de retour vide peut cacher une erreur. Il faudrait donc la traiter tel quel, et ne considérer qu'une valeur n'est bonne que si elle respecte un format particulier. Arprès, envoyer des messages simples à javascript, ne révélant aucun fichier, etc, pour effectuer une alert() dans le cadre d'un débogage, et désactiver le alert() en production. S'il y a une erreur, le méchant qui voudrait lire le message se trouvera en face d'un message dont il ne peut rien faire. On peut aussi détecter l'adresse IP en php, et envoyer un message d'erreur si en débogage, et ne rien envoyer en production (mais ce sera considéré quand même comme une erreur ... et alors JavaScript pourra dire au client "Nous sommes désolés, une erreur inconnue a eue lieu"). bref, tout est possible, tout est imaginable ;)