Hi Nicolas,
Thanks for the extensive and interesting reply. I'll try to answer
your questions below.
>> $mailer = new sfMailer(new Swift_Connection_SMTP('smtp.host.tld'));
>
> Here, how can you manage the environment? Like this?
You don't. Passing a native Swift connection is just an option of the
many I provided as example.
As shown in my example, sfConfiguredMailConnection would take care of
reading a YAML file, the factories.yml or whatever else to gain
information about a given named connection. This way you can use
multiple mail connections in the same environment, different
connections in different environments or whatever you like.
Substituting the constructed object by its connection name or using
the 'default' connection at all would result in a very short syntax.
Still you would be able to use all of Swift's features, which is
really important IMO if you don't want to enter maintenance hell.
> Also, I find a bit strange to define a mailer directly in a controller, I
> would personnaly prefer if
> you just set the connection name you want to use only if you need to.
I agree a bit. One solution would be to provide a global sfMailer like
it's done with the sfDatabaseManager. On the other hand,
$mailer = new sfMailer();
really is not much to write, pretty straight forward IMO and gives you
a lot of the flexibility provided by Swift. I'm not sure whether
dropping that flexibility would compensate for the cost of this line.
>> Note that sfMailer should extend Swift to inherit all its capabilities.
>
> That's what I'm currently planning to do, but this will end by
> strongly coupling Swift and symfony. I don't see any danger right now,
> though.
Do you think that's a bad point? I actually don't. Swift will be
bundled with symfony anyway, and it's a really feature rich library as
I've seen so far. I'd say go for it.
If the need should arise to make the plugin compatible with other mail
libraries (which I doubt) there'd still remain the possibility to
rename it to sfSwiftMailerPlugin and create a plugin with the same API
for that library (as with sfPropelPlugin vs. sfDoctrinePlugin).
> Well, how can you use the same action to handle both html and plain
> text templates with your last example?
Swift does provide that opportunity. You can just use two different
partials for it.
Usually this is done using message parts, but you could either inherit
your own message part class:
$message->attach(new sfMailPart('module/email.txt', array('var' => $var));
$message->attach(new sfMailPart('module/email.html', array('var' =>
$var), 'text/html'));
or you create a shortcut in sfMail (again, the big question is whether
that's worth it):
$message->attachPart('module/email.txt', array('var' => $var));
$message->attachPart('module/email.html', array('var' => $var), 'text/html');
> How do you use a component or
> partial template as a mail template source? If all is magic, how are
> you defining the template names to load? Maybe I'm missing something?
> Maybe I'm wrong here, but I think users should be able to send emails
> whith any template source, including symfony ones but others as well:
Regarding components/actions/partials: I think, mails itself usually
don't have any logic attached to them. The only logic evolves around
sending the mail. That's why I used partials for mail contents. You
can store them in any module (or in the global templates dir), so
modifying them together with the other templates is easy. You can have
any format in the partial, pass variables and have loops in them. I
consider using components or actions for that a bad practice.
> - using a module/action and its associated templates (and have email
> layout handling)
> - using a component
See above. A valid point is the layout stuff, but is this needed in emails?
> - defining a callback
By allowing defining a callback as the second argument of sfMail.
$message = new sfMail('My subject', array('class', 'callback'));
> - using file?
By allowing a file as the second argument of sfMail.
$message = new sfMail('My subject', '/my/file/path');
If that's too much magic, create different subclasses of sfMail or let
the application developer define his own subclasses. Since
sfMailer::send() allows sending of any class inheriting Swift_Message,
you don't have any limits really.
Don't get me wrong, I totally agree about making sending mails easy. I
just would like to avoid making everything that the plugin developer
doesn't think of unnecessarily complex.
What is your use case for creating the complex template logic
(layouting, action templates...) that you are proposing?
Bernhard
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
