HI Luis,
I'm more than happy to explore some ideas with you. I think the current mail service is pretty great. I think the main value we can add is in some helper methods to clean up the implementation from the users standpoint.
From what I understand, it currently accepts all the same arguments as the cfmail tag, correct? I think being able to set any/all of these in the settings, and then override on a per-payload basis makes a great deal of sense to me, default from, ssl etc etc.
Other areas that I think could use improvement:
MailParts
At the moment, if I want to send both an HTML and a text version of an email, I have to do something like this:
local.email.addMailPart(charset='utf', type='text/html', body='<p>Here is some text</p>');
and
local.email.addMailPart(charset='utf', type='text/plain', body='Here is some text');
This to me seems a little verbose. I can see exactly why you did it this way, because it mimics the cfmail behaviour, however, in reality, for each mail part you really only have two options, plain of html, and you can only have one of each anyway.
I'd perhaps suggest masking this with some helper functions:
local.email.setHTML('<p>Here is some text</p>');
local.email.setText'('Here is some text');
You could still keep the existing mail part methods in place to maintain backwards compatibility and for those who wish to have more explicit definition over what charset they use etc.
Attachments
As with the mail-parts, these at the moment mimic the behaviour of the cfmail implementation. Which is quite fine, but I think you could perhaps make this simpler again with some helper methods:
addAttchment('/path/to/the/attachment');
again, the current implementation could remain in place, it's just about making general everyday use a little simpler.
Convention Based Views
It'd be great if we could define a set of conventions for views to be used as email, the same way we do for standard events. These could be defined in a particular directory, or conform to a particular name convention. i.e.
Handler called ContactUs.send()
It assumes the use of views:
/views/contactus/send.email.html.cfm
/views/contactus/send.email.plain.cfm
or something along those lines, ensuring you can define views for both email formats.
Helpers For Common Mailparams
Being able to set custom mail params is a great feature in cfmail, but sometimes remember how to define them can be a pain, we should perhaps add helpers to the payload for commonly used ones.
setHighPriority()
setReadReceipt()
setSendReceipt()
Those are my initial thoughts.
Let me know what you think. If you want to discuss anything on IM then let me know.
Cheers Luis,
Robert
