+1 for putting this in factories.yml and extending sfContext to accept custom factories from plugins and the project.
It's my understanding the 2.0 service container will be flexible in this way (per Fabien's presentation at sf camp), so this change to sfContext would also serve forward compatibility. Kris On Sep 15, 2008, at 8:25 AM, "Nicolas Perriault" <[EMAIL PROTECTED]> wrote: > > On Mon, Sep 15, 2008 at 3:17 PM, Thomas Rabaix <[EMAIL PROTECTED] > > wrote: > >> My assumptions : sf1.0 has a nice way to handle mail : easy to use >> and >> quickly understanble by everyone. Agree ? > > Well, do you mean that? http://www.symfony-project.org/cookbook/1_0/en/email > > I don't like that much the "all-in-the-controller" approach, even if > it's true that you can move the code into another protected method, > even in a parent stub class (actually that's what I've done in > symfonians.net, but I'm not happy with it, even if it works). > >> $this = Controller >> >> $this->sendMail(array( >> 'mailClass' => 'sfMail', >> 'action' => 'module/mail', >> 'template' => 'my_template', >> 'layout' => ''email_layout', >> 'vars' => array( >> 'invoice' => $invoice, >> 'file' => new sfFile(), // can generate a unique identifier for >> the file >> ); >> )); >> >> of course some of this value could be guessed by the sendMail or >> defined in a yml file. > > With what I've in mind, mail sending in your action would be quite > similar to: > > $email = new InvoiceEmail(); > $email->setVars(array('invoice' => $invoice)); > // may be $email->addVar('invoice', $invoice); > $email->send(); > > And in InvoiceEmail.class.php > > class InvoiceEmail extends BaseEmail > { > public function configure() > { > $this->setHtmlContentResolver(sfEmail::FROM_ACTION, array('mail', > 'invoice')); > $this->setTextContentResolver(sfEmail::FROM_ACTION, array('mail', > 'invoice'), array('sf_format' => 'txt')); // notice the sf_format > trick > // or $this->contentResolvers['text/html'] = new > sfEmailTemplateAction('mail', 'module'); ? > > $invoice = $this->getVar('invoice'); > > $this->setSubject(sprintf('Your order #%s', $invoice- > >getOrderNumber())); > $this->addTo($invoice->getCustomer()->getEmail()); > $this->addBCC('[EMAIL PROTECTED]'); > $this->attachFile($invoice->asPDF(), 'invoice.pdf', 'application/ > pdf'); > } > } > > Two templates should then exist in the mail module templates folder, > invoiceSuccess.php and invoiceSuccess.txt.php. Okay, I don't like the > set*ContentResolver method calls but I guess that's why I'm asking for > better ideas here ;-) > > The idea here is to move the email logic from the controllers to > something apart, as what has been done with forms. > >> As the sendMail is not welcome anymore in the controller, a mail >> class >> (let's say sfMailComponent) can register to listen [1] to the >> controller.method_not_found event, and retrieve 'sendMail' call. > > Way hacky, isn't it? I don't know. People, express yourself :-) > > ++ > > -- > Nicolas Perriault > http://prendreuncafe.com - http://symfonians.net - http://sensiolabs.com > Phone: +33 660 92 08 67 > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
