CLASSE SIMPLE EMAIL
cs_depression
Messages postés
100
Date d'inscription
mardi 7 novembre 2000
Statut
Membre
Dernière intervention
13 juillet 2009
-
8 mai 2008 à 13:11
cs_Odradek Messages postés 4 Date d'inscription mercredi 7 mai 2008 Statut Membre Dernière intervention 9 mai 2008 - 9 mai 2008 à 22:43
cs_Odradek Messages postés 4 Date d'inscription mercredi 7 mai 2008 Statut Membre Dernière intervention 9 mai 2008 - 9 mai 2008 à 22:43
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/46590-classe-simple-email
https://codes-sources.commentcamarche.net/source/46590-classe-simple-email
9 mai 2008 à 22:43
Quand je disais "aussi fatigant", ça voulait dire que je trouvais cela équivalent (d'où le "aussi") en terme de quantité de code et pensant que tu parlais des return pour économiser du code je contre-argumentais la dessus, d'autant plus que les return sont plus évidents pour moi donc ce n'est vraiment pas une question de paresse... Maintenant effectivement je comprend mieux ton point de vue sur les exceptions.
9 mai 2008 à 22:24
Dans mon sens saoulant = fatigant.
Sinon, y'a une erreur là:
if($exp = filter_var($exp,FILTER_VALIDATE_EMAIL))
dans le meilleur des cas, c'est ==, mais il vaut mieux tester si tu reçois false:
if(filter_var($exp,FILTER_VALIDATE_EMAIL)===false)
Pour ce qui est des exceptions, c'est simple. Une exception doit rester... une exception et non pas une règle, et puis un utilisateur ne pensera peut être pas au fait que tu ais utilisé des exceptions et soit obligé de faire un try / catch sous peine de voir planter son programme.
Imagine qu'il y ait:
prise de commande
validation de la commande
envoi d'un mail
autre traitement
s'il ne pense pas à faire un try / catch et que par malheur ta classe sorte une exception non traitée, la partie qui suit l'envoi du mail ne sera pas faite.
Maintenant, si tu as envie de bosser de cette manière, dans cette philosophie après tout pourquoi pas :) le tout c'est de choisir et de t'y tenir.
9 mai 2008 à 22:06
la méthodes is_email.
(Euh sinon je ne sais pas ce qui te laisse croire que faire une classe me "saoule", c'est
une analyse tout à fait hors contexte à laquelle tu te livres en me prétant ce sentiment.)
D'autre part (je reprecise encore que la POO est trés neuve pour moi) je ne comprends
pas pourquoi faire des return serait plus pratique que faire des exceptions, quand doit
on décider d'utiliser des exceptions et pour quelles raisons ? Quel type de contraintes
apporte un try/catch à l'utilisateur?
Je tiens à préciser que ce sont des vrais et candides questions...
9 mai 2008 à 21:20
Ceci dit, pour les exceptions, je trouvais juste lourdingue d'obliger l'utilisateur de ta classe à utiliser un try / catch dans le code principal, c'est tout :)
Ceci dit, tu utilises $confirmation dans ta classe, mais il n'est jamais initialisé, il sert à quoi?
A moins que ce soit le résultat du mail?
return "Your email have been sent";
dans ce cas il faudrait plutôt faire: $this->confirmation="Your email have been sent";
-> Bon, sinon ça sert pas à grand chose de faire le ==TRUE:
if(($this->verifAdMail($this->exp)&&$this->verifAdMail($this->dest)
&&$this->verifCont($this->cont)&&$this->verifSubject($this->subject))==TRUE
soit tu ne mets rien (pas de ==TRUE), soit tu mets ===TRUE pour vérifier qu'en plus c'est un booléen, mais bon, très honnêtement vu que c'est ton code, tu peux t'en dispenser.
D'autre part, comme tu mets des throw exception partout au cas où la vérification échoue on se demande même si ça sert à quelque chose de mettre ça dans un if? Autant faire appel aux méthodes directement vu que ta classe va "planter" en cas de problème.
$this->verifAdMail($this->exp);
$this->verifAdMail($this->dest);
$this->verifCont($this->cont);
$this->verifSubject($this->subject);
-> Ensuite, pour ta vérification d'email:
private function is_email($exp){
if(!empty($exp)){
$exp = filter_var($exp,FILTER_VALIDATE_EMAIL);
Ca peut ne pas être correct. En effet filter_var renverra bien un email dans le cas où $exp est un mail correct, mais il peut également renvoyer un booléen false si le check a échoué! Dans ce cas $exp ne sera pas empty mais $exp sera failse mais ta fonction renverra true...
D'autre part, tu changes la valeur de $exp, ce qui pourrait poser soucis par la suite...
Pour les fonctions non compatibles Windows, tu peux déjà voir si elles sont accessibles par des tests sur l'existence des fonctions.
Comme disait mon prof d'informatique: "un bon programmeur est un fainéant, il fait aussi peu de code possible." mais ça n'est pas à prendre non plus au pied de la lettre. Si déjà faire une classe te saoule (return) imagine plus tard dans un vrai soft... Tu ne vas pas pouvoir caser des exceptions de partout sinon imagine la tronche de ton code.
9 mai 2008 à 20:52
Concernant la fonction mail, et la fonction checkdnsrr j'étais au courant et c'est un choix par facilité, cette classe n'étant destinée qu'à m'apprendre à correctement créé des classes, de plus l'existence de classes trés complètes comme celle de phpguru me fait penser qu'il n'est pas nécessaire de s'investir plus que de mesure dans celle-ci.
LMAME :Que penses-tu de mes nouvelles vérifications dans la méthode sendMail()?
Concernant les exceptions, il s'est agit pour moi d'apprendre à m'en servir,
cependant il me semble que mettre des return est aussi fatigant que de lancer
des exceptions.De plus les exceptions étant placé maintenant dans les méthodes
de vérifications cela me fait économiser un peu de code (ou pas ?).
9 mai 2008 à 18:01
C'est juste que je sais que je n'utiliserai pas une classe en l'état qui ne fonctionnerait qu'avec ça, ça revient à écraser une fourmi avec un caterpillar.
Il y a évidemment d'autres solutions comme le "message" qu'il appliquait avant qui pourrait contenir le message d'erreur (ou de validation) et les méthodes renvoyer dans ce cas un booléen en cas de succès / échec. Mais bon, après c'est une religion personnelle je suppose ^_^
9 mai 2008 à 16:15
9 mai 2008 à 12:28
-> Tu utilises des fonctions checkdnsrr qui ne fonctionnent pas sous Windows (cf help PHP),
-> l'utilisation de "mail" est parfois bridée chez les hébergeurs et peut virer au cauchemar dans le cadre d'un serveur perso, donc je rejoins depression, prévois un cas où tu peux utiliser un serveur SMTP avec login / mot de passe,
-> tu encapsules ton code dans un if pour l'envoi du mail:
if(!empty($this->exp)
&&!empty($this->dest)
&&!empty($this->cont)
&&!empty($this->subject)){
autant faire un return si une des variables est empty (à la première), le code sera plus lisible, ça fait une indentation pour rien là, d'autant plus qu'au final tu testes les variables deux fois avec le else ensuite.
-> je pense qu'il manque aussi la gestion des erreurs dans tes "set":
public function setDest($dest){
if($this->verifAdMail($dest)){
$this->dest=$dest;
}
}
Si le $dest est incorrect, le $this->dest sera donc à "" et dans le meilleur des cas ton utilisateur aura un message "Le champ du destinataire est vide". Or il était pas vide, il était incorrect.
Bref peut être que tes setxxx devraient revoyer true ou false (ou un message d'erreur) selon que la verif a marché ou non. Comme ça tu pourrais dire à l'utilisateur "adresse mail incorrecte" ou un truc dans le genre.
Dans ton code "principal":
-> tu fais un try / catch dans ton code. C'est sympa, mais un peu inutile à mon sens. Si le mail n'a pas été envoyé, renvoie un booléen ou un message texte plutôt par un return classique.
D'autre part, sauf erreur je vois qu'en cas de mail envoyé avec succès tu utilises $this->message... Or cette variable n'est jamais utilisée (dans le code principal ou la classe), ni même définie dans la classe?
Bref un return "mail envoyé avec succès" ou return "erreur lors de l'envoi du mail" me semble suffisant. Lever une exception pour ce style de code me paraît too much, surtout si quelqu'un utilise ta classe ensuite.
8 mai 2008 à 13:31
8 mai 2008 à 13:11
- Tu devrais faire preuve de constance sur le nom de tes méthodes. Des fois tu notes fooBar, et d'autres FooBar. Il faut que tu définisses et que tu suives une convention de nommage stricte.
- Pour la forme, tu devrais quand même écrire un constructeur, même s'il est vide.
- Ta regexp d'email est trop stricte. Beaucoup de mails valides pourraient ne pas passer. Puisque tu es en PHP5, tu pourrais utiliser l'extension Filter apparue depuis PHP5.2
Bien, voici ce que tu devrais coder pour la suite:
- Gestion d'envoi de mails en HTML
- Gestion d'envoi de pièces jointes
- Envoi de mail en passant par un serveur SMTP