Hi devs,
As you may know, I'm in charge of providing a standard way to send
emails within symfony 1.2. I'd like to get your feedback and ideas
about the way the SwiftMailer library goodness should be integrated.
Currently I've just played with Swift and nothing has really been
started by my side, so everything is still possible =)
To me, the main important thing if to be able to use a different
mailer dependending of the environment: maybe in dev mode you doesn't
want to send real email, but just want to generate them and store them
on your local filesystem (or anywhere you want), as the sfEmailPlugin
does. That would be possible using the factories.yml file, like this:
prod:
mailer:
class:
sfMailerSmtp:
server: foo.bar.tld
port: 25
username: foo
password: bar
default_sender: Toto Mailer <[EMAIL PROTECTED]>
all:
mailer:
class:
sfMailerLocalFilesystem:
path: %SF_LOG_DIR%/emails
My main concern here is that it will be hard to bundle it as a plugin,
because I do not know any way to hook/override the factories
configuration in symfony within a plugin context... Maybe a smart
approach would be to provide base abstract classes in the symfony
core, and the plugin would provide a Swift based implementation? I
don't know, but it looks like if not possible, we'll must implement
this feature in the core...
I was also thinking about creating dedicated message classes (as Swift
already does) but with native symfony-based mail contents generation
available, to ease mail objects reuse. Maybe something like this
(rough draft):
$email = new sfEmail();
// then
$email->setHtmlContentResolver(sfEmail::FROM_ACTION, array('mymodule',
'myaction'));
// or
$email->setTextContentResolver(sfEmail::FROM_PARTIAL,
array('mymodule', 'mypartial'));
// or
$email->setTextContentResolver(sfEmail::FROM_COMPONENT,
array('mymodule', 'mycomponent'));
// or
$email->setTextContentResolver(sfEmail::FROM_STRING, 'hello world');
// and maybe
$email->setContentResolver('text/html', sfEmail::FROM_STRING, 'hello world');
// why not
$email->setContentResolver('application/pdf', sfEmail::FROM_FILE,
'/tmp/toto.pdf');
// there could be also sfEmail::FROM_CALLBACK and so on
// then
$email->send();
It's a bit verbose, eh? Maybe we can also use dedicated classes for
email templates, eg. sfEmailTemplateAction, sfEmailTemplateComponent,
etc., but maybe it's a bit bloated by design for the purpose of just
sending emails? Swift has native support fr template, maybe just
extending it with these sfEmail templates classes could be a solution?
For custom reuseable emails, we should be able to easily create
dedicated email classes:
class myEmail extends sfEmail
{
public function configure()
{
// configure the email here, eg.
$this->setSubject('Hello there');
}
}
These classes would be stored in a new lib/email directory by default,
maybe with a stub BaseEmail class available for user level generic
implementation purpose: sfEmail < BaseEmail < myEmail.
At the end, I would like to be able do do things like that:
class fooActions extends sfActions
{
public function executeBuy($request)
{
if ($request->isMethod('post))
{
$email = new myEmail();
$email->addTo('[EMAIL PROTECTED]');
$email->setVars(array($request->getAttribute('stuff')));
$email->send();
}
}
}
So here are my actual thoughts. What are your ideas and suggestions?
++
--
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
-~----------~----~----~----~------~----~------~--~---
