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

Honza M. napsal(a):

Nevim na co je dobrej nette mail bez šablon :-)

Souhlas :)

https://api.nette.org/…eb.Mail.html ale chce to odladit, zejména kódování quoted_printable. Podpora šablon zatím není.

ps. vycházel jsem z tohoto dokumentu, perfektně popsané pro lidi, co o MIME nic neví (jako ještě před chvílí já ;)

Fajn! Dobré zprávy po ránu. Bude ještě součástí nějaké rozhraní nebo už je to zbytečné?

Člověk tu oroduje za rozhraní a ona se z toho vyklube classa :-) Super, díky moc!

Podľa mňa to až také zlé nebude :)

class MyZendMail extends /*Nette\Web\*/Mail
{
    public static $mailer = 'zendMailer';

    // funkcia Mail::send() nie je polymorfná...
    public function send()
    {
        return call_user_func(
            array(get_class($this), self::$mailer),
            $this->build()
        );
    }

    private static function zendMailer($message)
    {
        Debug::dump($message);
        // tu už môže prebehnúť nastavenie pre Zend_Mail
        // a aj odoslanie pomocou neho.
    }
}

Alebo Nette\Web\Mail nebola zamýšľaná na takéto rozširovanie?

Když budeš chtít vyměnit mailer, tak to bude nejspíš kvůli nějaké pokročilé funkčnosti. A ta v interfacu velice pravděpodobně nebude.

Původní návrh byl tuším spíš taková nouzovka. Já jsem si od toho sliboval, že vznikne několik adaptérů na různé mailery s lidským a stejným ovládáním a každý si bude moct vybrat jemu sympatický. Naším tajným přáním vždy bylo mít nativní mailovací knihovnu v nette :-D

Já od něj čekám především šablony, které ještě neumí. Z Objectu dědí snad všechny třídy frameworku. A fluent bych taky uvítal.

Ještě mě napadla taková možnost, co kdyby Nette/Mail byl jenom objekt, ve kterém by se udržovaly všechny informace o e-mailu a poté by se tento objekt předal nějakému maileru/adaptéru, ten už by si e-mail zpracoval, jak uzná za vhodné. A mailer/adaptér, by musel pouze akceptovat na vstupu objekt Nette/Mail. A pomocí něčeho v config.ini by si člověk zadefinoval, co bude chtít používat jako výchozí mailer/adaptér. Co vy na to (pane Kraus)? :)

Shrnutí

Měli bychom:

Nette/Mail

Ten by obsahoval hotový email se všemi informacemi. Posléze by se předal:

Nette/Mailer

Který daný e-mail (Nette/Mail) odešle. Chtělo by to možná vymyslet, jak do tohoto objektu naimplemetovat nějaká extras, třeba nějaké hodnoty s kterými se nepočítalo. Navrhuji udělat pole, které si poté zpracuje každý mailer podle sebe.

Nette/IMailer

Obsahoval by public function send(Mail $mail,$extras/* viz Nette/Mailer */);. Toť vše.

Jak by to mohlo vypadat v kódu?

$m = new Mail(/* Environment::getConfig("Mail") */);
$m->defaults = Environment::getConfig("Mail"); // Nastaví výchozí hodnoty Mailu, odesílatele, atd. (opravdu usnadní život :) (alternativa pro variantu volanou přímo v konstruktoru)
$m->from = "...";
.
.
/* Ve výchozím nastavení už byl určen Mailer */
$mr = $m->mailer;
$mr->config = Environment::getConfig("Mailer"); // Nastavil by automaticky z config objektu hodnoty
/* Něco bychom změnili */
$mr->host = "127.0.0.1"; // Mailer je navržen na posílání přes SMTP -> nastavuji host. Jiný mailer třeba nebude mít žádné nastavení.
/* Mailer musí implementovat rozhraní IMailer, které by obsahoval metodu send(Mail $mail); */

$m->send(); // Zde by se vlastně v pozadí davolalo $mr->send($m);

Co vy na to? :) (kopal jsem na zahradě trativod, tak jsem měl čas na přemýšlení, proto je to takové delší :)

//EDIT: Tošku jsem to rozepsal :)

Editoval honzakuchar (26. 5. 2009 21:38)

kdo sleduje daviduv twitter tak vi, ze david uz asi vytvoril vlastni mailovaci tridu, takze nebude treba zadnych rozhrani… :)

Nevim, to co je na SVNku, mi to přijde dosti zmatené nebo jsem to vůbec nepochopil. Jak třeba do toho zavést SMTP (další mailery? dědit třídu? divný ne?)?

Spíš nepochopil. Mělo by fungovat něco takového, pokud si vyrobíš třídu SmtpMailer:

$mail = new Mail;
// nastavení mailu

$smtpMailer = new SmtpMailer;
$mail->mailer = array($smtpMailer, "send");
$mail->send();

Dlouho jsem odolával napsat Nette\Mail, protože mi to připadalo jako něco těžkého a obrovského. Nakonec to byla celkem hračka. Základ by měl být funkční, postupně přidám podporu pro šablony a nejspíš i SMTP odesílání. Bude fajn, když to důkladně otestujete.

Ad „Interface“: popravdě nevidím v tom žádný přínos. Zkuste se reálně zamyslet, k čemu mít jednotný interface pro různé mailery, které dělají de facto to stejné?

Ad „Mail jen jako popisovač:“ v podstatě to tak funguje. Vlastní mailer lze aktuálně nastavit dvěma způsoby:

function debugMailer($mail)
{
	file_put_contents('email.eml', $mail->generateMessage());
}

// 1. varianta
Mail::$defaultMailer = 'debugMailer';

// 2. varianta
$mail = new Mail;
...
$mail->send('debugMailer');

Asi jsi tam na řádku 110 zapomněl nějaké echo a v dokumentaci používáš v ukázce s presenterem třídu Mail místo PTemplateMail.

super, diky za objasneni. Pokud bude trida nette/mail spolehliva, tak to bude urcite veliky prinos. (omlouvam se za natvrdlost, zil jsem v tom ze to bude fungovat jinak, ale uz jste me presvecili, integrace maileru do frameworku je asi opravdu nutnost a kdyz prinese i neco noveho, treba sablonovani :)

No jak je navržená tahle třída, též vznikne prostor pro vlastní řešení. Je to dobře vymyšleno. A popravně nevím, co by mít interface na mailer vlastně přineslo. Protože to jak to funguje teď, je velice podobné tomu, jak jsem to navrhoval zde (byl jsem také zastáncem IMailer a Mailerů). Tyhle 2 řešení mi přijdou ve své podstatě shodná, až na to, že mi rozdělení do tří částí (Mail,IMailer,Mailer) přijde přehlednější a jasnější. U tohoto řešení mi chvíli trvalo, než mi došlo, jak to vlastně funguje. Ale funkčně jsou obě řešení rovnocená (alespoň mě nenapadají žádné rozdíly).

honzakuchar napsal(a):

Nemyslel jsem (alespoň já) mailerem třeba PHPMailer. Myslel jsem, že v nette budou vlasní mailery. Jeden třeba pro posílanání přes SMTP, druhý přes funkci mail(),… A když by někdo chtěl používat něco „navíc“, tak by si třeba udělal adaptér, který by implementoval rozhraní IMailer stejně jako Mailery v nette. A mohl by to to používat.

Jo takhle! Chápal jsem to úplně jinak, návrh interface spíš připomínal rozhraní pro uživatelskou část, než pro samotný odesílač.

Ale znova opakuji, jediný rozdíl mezi řešením od Davida a řešení s Interface mi přijde v přehlednosti. Nebo se přece jenom nějaký rozdíl najde? :)

Ano, callback vs. interface.

Callback je flexibilnější a jednodušší. Hodnotou může být funkce, metoda nebo objekt (v PHP 5.3). Interface představuje čistě objektové řešení, hodnotou může být jen objekt. Interface je ukecanější, musí existovat soubor s interface + třídu, výchozí implementací. Nicméně interface je mnohem silnější prostředek. Callbackem lze nahradit jen interface, který má právě jednu metodu.

Celá věc stojí asi takto: buď se použije callback, nebo se použije interface a celá věc se přesune do nového jmenného prostoru Nette\Mail. Co myslíte?

Ochutnávka v. 0.2

/* Defaults */
MMail::setDefaultMailer(new phpMailerAdapter)/* Returns IMailer */
->setConfig(array(
  "Host"=>"mail.karneval.cz",
));
MMail::setDefaults(array(
  "From"=>"Jan Kuchař <honza@test.cz>",
));


$m = new MMail();
//$m->from = "Pepa Pokusný <ahoj@test.cz>";
  // $m->from je object, takže k němu můžeme přistupovat i takto: $m->from->email; nebo $m->from->name;

/* Můžete používat též $m->addTo("Jan Kuchař <honza@test.cz>"); */
$m->addTo("honza@test.cz","Jan Kuchař");
//$m->addCc("honza@test.cz","Jan Kuchař");
//$m->addBcc("honza@test.cz","Jan Kuchař");
//$m->removeBcc("honza@test.cz");
//Debug::dump($m->bcc);

//$m->replyTo = "Jan Kuchař <test@pokus.it>";

$m->subject = "Test";
$m->priority = MMail::PRIORITY_HIGH; // Default is NORMAL

//$m->messageType = MMail::TEXT; // Now autodetect

/* Ukázka autodetekce obsahu */
  /* Body nastavovat až po definování všeho - jinak nebude možnost přepsat hodnoty mailu */
  $m->body = $m->fromTemplate(
    new Template, /* new Template or Presenter */
    dirname(__FILE__)."/test.phtml", /* This is only shotrcut */
    TRUE /* CurlyBrackets? */
  );
  $m->body->someVar = "test";
  //$m->body = "Ahoj jak se mas. Tahle zpráva bude v textovém režimu.";
  //$m->body = "Ahoj jak se mas.<br>Tahle zpráva bude v html režimu.";
/* Ruční přepsní */
  /*
  $m->messageType = self::TEXT;
  $m->body = "Tato zprava bude v textovem režimu. <br> asdasdasdasdasd. (BR bude v textovém režimu)";
   */

$m->send(/* Here you can also set mailer, but only with default settings */);

Ukázka templatu

Textový template

{?
  //$mail->subject = "Předmět";
  //$mail->messageType = MMail::TEXT; // Může být a nemusí, pokud se v mailu nevyskytují html tagy, tak se automaticky rozpozná, že email je textový
}
Test z templatu :)
asdasd
asd

HTML template

{?
  //$mail->subject = "Předmět";
  //$mail->messageType = MMail::HTML; // Může být a nemusí, pokud se v mailu vyskytují html tagy, tak se automaticky rozpozná, že email je html
}
Test z templatu :)<br>
<b>asdasd</b>
asd

Metody jsou už plně fluentní.

Stahujte

Vývojovou verzi můžete stahovat zde.

Prosím napište mi feedback.

Co tahle verze ještě stále neumí?

• Soubory
• Vložené obrázky
• Víte o něčem, co se ještě používá často?

Editoval honzakuchar (28. 5. 2009 22:14)

Proč na to nevyužiješ Nette\Mail, který přiložené obrázky posílat umí a nepotřebuje PHPMailer?

(já mám pocit, že mi tohle téma nějak uniká… budete mi to musit vysvětlit v sobotu :-)

Já taky pořádně nevím k čemu to všechno, ale tak třeba to má nějaký hlubší smysl :)

Koukám, že na svnku už se objevil IMailer, moc pěkné :) Jen mě napadlo, jestli by nebylo hezčí, kdyby se jiný než defaultní mailer mohl předávat už v konstruktoru? Předávat ho až v send()…nevim…proč to tak vlastně je? Asi to nějaký smysl má?

Editoval Warden (28. 5. 2009 21:41)

Feature request: Uvítal bych, kdyby se při neodeslaném mailu vyhodila výjimka.

honzakuchar napsal(a):

2. Smysl: Význam to má asi tak stejný, jako Nette/Mail. :) (odesílat maily)

Tedy jde o alternativu pro Nette\Mail. Tož jako proč né, ale měl jsi to napsat o týden dřív :-)) V této chvíli už mám pocit, že to jde trošku mimo Nette. Nicméně fandím tvé snaze, napsat si mailer je dobré cvičení.

P.S.: Jak tak vidím, tak se David s tím interface inspiroval. :) (IMailer)

Ano, interface mi připadá čistší; nadhodil jsem tohle téma včera, ale popravdě už když jsem se ptal na názor, byl jsem rozhodnut.

Na počátku byly Maily, spousty Mailů, složitých, tajemných a ďábelských – až přišel Nette člověk

1. Nette člověk chtěl svatý Mail, který by jej ochránil od nástrah ďábelských Mailů – a byl odmítnut.
2. Všichni Nette lidé chtěli svatý Mail, který by je ochránil od nástrah ďábelských Mailů – a byli odmítnuti.
3. Nette člověk se rozhodl vytvořit vlastní Mail, který by jej ochránil od nástrah ďábelských Mailů.
4. Bůh stvořil svatý Mail a dal jej Nette lidem.
5. Nette člověk zavrhl svatý Mail a stvořil Mail svůj, spolupracující s Maily ďábelskými.
6. ?

Ani už nevím, v kterém tom kroku jsem tuhle diskuzi přestal chápat, ale děkuji Davidovi za pěknou třídu, děkuji Honzovi za pěknou třídu a teď, když mě omluvíte, musím si jít napsat svůj zbrusu nový Mail…

P.S. Pokud se vás tento článek dotkl, pravděpodobně se díváte na svět moc vážnýma očima – ale pevně věřím, že se nic takového nestalo=)

honzakuchar napsal(a):

S těma Mail(er)ama to dopadlo skoro stejně jako u flashMessagingu. :) Možná by to chtělo nějakou stránku s tím co se bude dělat a kdy (nějaký plán) a co už je hotovo. Nebo něco takového existuje?

To by nepomohlo. Protože bylo jasně řečeno, že něco tak složitého jako je mailování se v dohledné době dělat nebude ;)

1. Konfiguraci (výchozí nastavení Mail; nastavení Maileru – když bude odesílat přes SMTP, musím mu nějak předat tu konfiguraci, že :)

Tam se předá nakonfigurovaný objekt SmtpMailer například do Mail::$defaultMailer (časem bude nahrazeno asi za Environment). Výchozí nastavení maileru jsem neřešil, připadá mi čistší si udělat potomka. (cokoliv přes statické třídy je potenciální zlo.)

2. Nějakou zkratku na vytvoření mailu z templatu. (+ do templatu předat aktuální instanci Mail – $mail)

Jojo, podpora templates je velmi důležitá, ale komitnu to, až to budu mít perfektně vyladěné.

3. (detail) Neudělat na dvojici email a jméno třídu? S metovou __toSring(); Je to zase podle mě přehlednější a jednoduší. (v MMail je to EmailParticipant – mázase __toString(), kde to to převede do patřičného formátu) + EmailParticipantList (není implementováno, ale v __toString by se odělily EmailParticipant-i čárkami)

You Ain't Gonna Need It ;)

4. Podpora html/text mailu + ruční přepínání režimu + jako výchozí autodetekce (viz MMail)

To by mělo fungovat: pokud je nastaveno HTML, půjde o text/html email. Pokud chybí text, bude vygenerován z HTML.

5. Kontrola před odesláním – vyplnil jsem odesílatele? Vyplnil jsem předmět? vyplnil jsem tělo? → jinak výjimka.

Pravda, to by se asi mělo přidat.

Tak výborně. :) Když ty 3 body odškrtneme(bod 1. – souhlas; bod 4. je opravdu blbost :)), tak bude Nette/Mail lépe použitelné než MMail → budu ho pužívat :).

Ještě jsem objevil jednu věc, co používám na PHPMaileru:
Předám mu html (v případě Nette/Mail by to byl template) soubor. → co v něm najde obrázky automaticky je přidá do mailu (jako inline). Opravdu užitečné a jednoduché. A začátečníka to určitě osloví – je to takové hodně efektní. :)

Každopádně vývoj MMail je UKONČEN. :)

honzakuchar napsal(a):

Předám mu html (v případě Nette/Mail by to byl template) soubor. → co v něm najde obrázky automaticky je přidá do mailu (jako inline). Opravdu užitečné a jednoduché. A začátečníka to určitě osloví – je to takové hodně efektní. :)

Pokiaľ som to správne vyčítal zo zdrojákov, Nette\Mail\Mail má toto implementované (samozrejme len v prípade html tela), a ani pridanie šablón do buildovacieho reťazca by to nemalo nijako narušiť…