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
-~----------~----~----~----~------~----~------~--~---

Reply via email to