Nativní Nette\Mailovací class? Asi ne…Interface? ANO!

Honza M. napsal(a):

Možná by nějaký velice primitivní mailer mohl být i v nette, když stejně nette umí posílat maily s chybama.

Ja bych to do tohoto topicu moc nezahrnoval, nebo se to zase zvrhne k tomu, k cemu nechci…za chvili kazdy zacne pozadovat kvalitni Nette meilaer a puvodni myslenka pujde do kytek ;) Jinak k tomu navrhu, s tim bys souhlasil? Pripadne nejake napady…krome vlastni Nette mailer klasy :)

Mne bohato stačí TemplateMailer wrapper na Zend_Mail.
Ale integrovaná podpora by určite nebola na škodu, viď velmi užitočný počit Nette/Image, ktorý ma celkom nadchol, aj keď vyšiel trochu neskoršie než som potreboval =)

Jod napsal(a):

Mne bohato stačí TemplateMailer wrapper na Zend_Mail.
Ale integrovaná podpora by určite nebola na škodu, viď velmi užitočný počit Nette/Image, ktorý ma celkom nadchol, aj keď vyšiel trochu neskoršie než som potreboval =)

Jasně, to je podobný případ. Používání těchto, mezi sebou nekonzistentních, mail wrapperů mi nepřijde právě úplně nejšťastnější :-) Proč to tedy neobalit Nette interfacem, že ano? :-)

Tohle je užitečná featura, ale myslím si, že to už je něco „navíc“. Obecný setter hlavičky se dá implementovat po podědění případné Nette\Mail…tomu nic nebrání. Ale nejsem si jist, jestli to patří přímo do obecného rozhraní, které je předmětem tohoto topicu.

Pozor na to, ze email muze mit zaroven jak html, tak i textovou verzi. A myslim, ze sprava priloh by mela taky byt soucasti interface. Jak psal Warden,tak pokud nejaka konkretni implementace nebude neco podporovat, tak dana metoda proste vyhodi vyjimku…ale dle meho nazoru by obecny interface mel dovolovat implementovat pokud mozno vsechno.

Takže abysme nekecali jen tak obecně, tak můžem začít vymejšlet.

class MyMailer extends Object implements IMailer // tady nevidím moc prostor pro diskuzi, maximálně o názvech
{
	// základy
	settery a gettery pro subject, from, to, cc, bcc
	// tady je otázka, jak udělat ty settery
	// možnosti $mailer->setTo("Jméno <mail@mail.cz>") nebo $mailer->setTo("mail@mail.cz"[, "Jméno"])

	// práce se šablonou
	setTemplate(ITemplate $template);
	// konkrétní implementace klidně můžou mít nějakou línou továrničku createTemplate - viz Control
	getTemplate();
	// kvůli šablonám myslím není potřebné mít v maileru vůbec funkce setBody nebo setHtmlBody a tak

	// html e-mail?
	setHtml(boolean) a isHtml()

	// odeslání
	send();

	// přílohy
	addAttachment();
	// asi takto jako v phpMaileru? addAttachment($path, $name = "", $encoding = "base64", $type = "application/octet-stream")

	// nastavení kódování nebo hlaviček nějak, asi:
	setEncoding($encoding);
	setHeader($header, $content);
}

Takových věcí… hrůza :-D Kdo se s tim pak má implementovat :-D

Ano, ano, presne tu. Trošku som rozrušený tak mi to nemyslí :D

Nebylo by lepší místo InvalidStateException použít NotImplementedException?

Proč bych nevolil interface který by obsahoval vše? Protože pak příde někdo kdo chce udělat na wrapper na doopravdy sipleMailer… A wrapper by pak vypadal strašně, klidně i víc jak polovina metod by byla zbytečně ve tvaru:

<?php
function foo()
{
	throw new NotImplementedException("Foo není implementováno v tomto wrapperu");
}
?>

Je je snažší mít jednodušší interface. A u wrapperů které toho umí více mít přidané metody mimo interface než mí hodně rozsáhlí interface a třeba 80% kódu stejného.

Nebo je možnost 2há mít interface-i 2 „siple“ a „full“. Ale to mě příde už hodně překombinované.

Warden napsal(a):

S těmi settery, rozhodně bych volil setTo(mail[, name]);…jak se pak implementuje ono dosazení jména k mailu přeci nikoho z venku nezajímá.

Ja bych mozna radeji volil

	$mailer->setTo(array($name => $mail, $anotherName => $anotherMail));
	//hlavne se pak da pouzit i zjednodusene $mailer->setTo(array($mail, $anotherMail));
	//a asi by bylo hezke umoznit i zjednodusene $mailer->setTo($mail);
	//cili argument 'typu' mixed

Editoval arron (25. 5. 2009 12:00)

Warden napsal(a):

Nad tou classou Nette\Mail bych stejně ještě trošku popřemýšlel ;-) Přijde mi elegantnější používat třeba

$mailer = new Nette\Mail(new PHPMailerAdapter());

než vytváření

$mailer = new PHPMailerAdapter();

Tak máš ServiceLocator:

Environment::getServiceLocator()->addService('PHPMailerAdapter','Nette\IMailer');
// a pak
Environment::getService('Nette\IMailer');
// případně i zkratku
Environment::getMailer();

PetrP napsal(a):

Tak na to jsem jaksi pozapomněl, to by mohlo řešit.

S těmi metodami v rozhraní, jak jsem říkal, nejlepší bude vytáhnout ty, které se vyskytují třeba v 80% mailerů…ten zbytek nebude tak velký a jednoduchá zaměnitelnost komplexnějších mailerů je v podstatě nenarušena.

Editoval Warden (25. 5. 2009 12:13)

arron napsal(a):

Ja bych mozna radeji volil

	$mailer->setTo(array($name => $mail, $anotherName => $anotherMail));

To už mě příde hodně neintuitivní. To už raději další metodu

$mailer->setToMany(array($name => $mail, $anotherName => $anotherMail));
//nebo jinak pojmenovaná

$mailer->addTo(mail [, name]); +1. (tohle se mě líbí nejvíce)

arron napsal(a):

vrtak-cz napsal(a):

Je je snažší mít jednodušší interface. A u wrapperů které toho umí více mít přidané metody mimo interface než mí hodně rozsáhlí interface a třeba 80% kódu stejného.

Nebo je možnost 2há mít interface-i 2 „siple“ a „full“. Ale to mě příde už hodně překombinované.

Jenze tim se zbavis te nejvetsi vyhody, ze u tech pokrocilejsich maileru to vsechno bude fungovat stejne, protze ty pridane metody si kazdy implementuje rozdilne…kdyz budou definovane v interfacu tak to proste bude standardizovane a kdyz se uprostred projektu rozhodnes zmenit mailer, tak s tim nebudes mi zadny problem. To uz bych klidne sel cestou „simple“ a „advanced“.

Napadlo mě ještě jedno řešení. A to mít doopravdy rozsáhlý interface. Ale k němu ještě abstraktní classu která by měla standartně u „advanced“ metod dopředu nastaveno NotImplementedException.

Tady o tom že by sis musel tu classu podědit nebyla řeč.

A to mít doopravdy rozsáhlý interface. Ale k němu ještě abstraktní classu která by měla standartně u „advanced“ metod dopředu nastaveno NotImplementedException.

To jesli podědíš classu nebo jenom použiješ interface je na tobě.

Warden napsal(a):

Jasně že to je na mně, jde mi spíš o to, jestli to má nějaký větší smysl, dělat něco rozsáhlého, kde polovina metod bude u většiny mailerů NotImplemented, takže bude lepší podědit abstract a tím se připravím o možnost dědění z něčeho jiného. Nebo nepodědím, ale ručně budu implementovat polovinu metod jako NotImplemented…proto jsem mluvil o dědění.

Ja bych rekl, ze to smysl ma, protoze pak na ten interface nebudes muset dlouho sahnout. Kdyz to pojmes moc minimalisticky, tak se to bude muset porad upravovat, pridavat a bastlit.

Spíš si myslím, že je lepší cesta s výtahem nějaké trochu obecnější množiny metod ze známých mailerů (ne každá maličkost, co by se našla), aby onen podíl NotImplemented byl co nejmenší (ikdyž nějaké určitě budou) a mohli jsme pohodlně používat interface bez zbytečného zaplácávání metod vyhazováním vyjímek.

Co je obecnejsi mnozina metod?

A nechcete tu zkusit každý sepsat, co reálně používáte a podle toho by se udělal ten Interface?

Já bych určitě kromě základních věcí chtěl přílohy. SMTP jsem sice jednou využíval, ale myslím si, že to do základního mailu nepatří. Případně se může vytvořit třída SendSMTP, která bude přijímat IMail a odešle jej. Jinak žádné vychytávky nepotřebuji.

Obecnější množinu metod jsem měl na mysli metody, ktere kazdy pouziva. Treba to smtp se bezne nepouziva. Ja bych ho treba do interfacu necpal, ty bys ho tam asi chtel. Takhle nejak sem to myslel. Vyčlenit běžně pouzivane(samo je nejdřív najít;-) a z těch udělat rozhraní.

Z množstva príspevkov naozaj vidno, že je to žhavá téma :)

Čo sa implementácie týka, podľa toho ako sa v Nette pracuje s kešou alebo konfiguráciou mám pocit, že maily by mohli ísť rovnako, lenže pri mailoch bude asi ťažšie nájsť interface, ktorý nebude zbytočne nabubrelý ani nepoužiteľne jednoduchý…

A riešenie, že by Nette\IMailer mal lowlevel metódy ako setHeader(), addHeader() a Nette\Mail mal implementované setTo(), addTo() pomocou nich asi tiež neprejde, keďže väčšina mailerov nastavuje tieto veci metódami pre každý header zvlášť…

Abych pravdu řek, tak za největší přínos getterů považuju to, že pokud Mailer bude potomkem třídy Object, tak bude možné psát $mailer->subject = "Předmět" :-D

Potom bych ještě navrhnul, aby settery vracely $this kvůli řetězení.

Ten interface je opravdu gól. Opravdu tu něco takového chybělo. :)

Jak by měl vypadat adaptér. Pokud bude dědit od Object, tak nemůže dědit od maileru → předefinovávat všechny metody a proměnné znova? Bude to asi dost drbačka.

kravco napsal(a):

Pokiaľ má implementovať nejaké rozhranie, dediť od maileru by bolo trochu zvláštne – skôr by mal byť adaptérom. Tým pádom by sa rozhranie predsa len malo volať IMailerAdapter.

Jenže to, co se tu probírá je definování standardního rozhraní Maileru, tzn. v názvu by rozhodně žádný Adapter být neměl – to, že nejčastěji bude toto rozhraní implementovat nějaký adapter pro pokročilejší mailovací třídu, neznamená, že si nemůžu napsat SimpleMailer, který prostě bude jen umět odeslat textovou zprávu pomocí PHP mail().

Nikdy jsem asi nepoužil víc než tohle:

$mail->setFrom('Franta <franta@example.com>'); // alternativne setFrom('franta@example.com', 'Franta');
$mail->setSubject('Test email'); // v UTF-8 by default
$mail->addTo('Pepa <pepa@example.com>'); // alternativne addRecipient(), nebo addTo('pepa@example.com', 'Pepa')
$mail->addCc('Pepa <pepa@example.com>'); // nebo addCc('pepa@example.com', 'Pepa')
$mail->addBcc('Pepa <pepa@example.com>'); // nebo addBcc('pepa@example.com', 'Pepa')
$mail->setPriority(Mail::HIGH);
$mail->addHeader('X-MailGenerator', 'MyNetteApplication');
$mail->setTextBody('Sample text');
$mail->setHtmlBody('<b>Sample HTML</b> <img src="background.gif">'); // automaticky generuje textovou verzi
$mail->addEmbeddedFile('background.gif');
$mail->addAttachment('example.zip');
$mail->send();

Upravil jsem wiki stránku.

Zrušil jsem gettery, protože asi fakt nejsou potřeba. Místo metod addHtmlBody a addTextBody jsem nechal setTemplate, getTemplate a setHtml. Dále jsem zachoval setEncoding, protože se obávám, že bude potřeba.

Otázka je, jestli děláme interface pro šablonovací nebo obecný mailer. Já jsem pro šablonovací.

Kdo posíláte přílohy, tak napište, jaké si přejete parametry do metody addAttachment. Já nikdy přílohu neposílal, tak nevím, co je potřeba.

Editoval Honza M. (25. 5. 2009 20:42)

1. Co bude mít vyšší prioritu? Šablona nebo setHtmlBody a setTextBody?
2. To templatování mailů má pro mě velice speciální význam, protože v šabloně hodlám nastavovat i odesílatele, předmět a tak.