\Zend\Mail\Transport\File being used in place of a regular mail transport (like Smpt or Sendmail) instead of sending the mail just saves all email messages as they are in the file system. Source Code (Working version with unit-tests)
Proposed Component Name
(wiki revision: 11)
\Zend\Mail\Transport\File being used in place of a regular mail transport (like Smpt or Sendmail) instead of sending the mail just saves all email messages as they are in the file system.
Source Code (Working version with unit-tests)
WILL save outgoing email in the file system
MUST provide some standard way to generate file names
MUST let users to use their own algorithms for generating file names
MUST allow configuration through Zend_Application_Resource_Mail options
WILL NOT really send an e-mail message
When transport's internal sendMail() is called Zend\Mail\Transport\File takes prepared headers and body and dumps them in a file in the specified directory. Name for the file is generated based on the callback you provide. Standard callback uses 'ZendMail' . time() . '_' . mt_rand() . '.tmp' format.
Both path to the directory you want to save the files to and callback function may be passed to the transport's constructor in an array, which makes it also possible to be configured via the Zend_Application Mail resource like this:
So that it's convinient to use in development environments like default mail transport for various e-mail messagin testing without changing actual code at all.
If 'path' value is not set manually, default is defined by calling sys_get_temp_dir php function.
The callback used for generating filenames gets the transport instance as the only parameter, so that it can use email message details for composing the filename and also it can use default callback (let's say to prepend something to the filename it generates).
About different storage options / adapters etc. I suggest keeping this transport as easy as it is now. It would allow great but simple posibility for different email messaging testings especially for systems where bulk emails and mass messaging take place.
For different storage formats (if it is required and desirable to be implemented as a Zend_Mail transport) I suggest implementing another transport, like \Zend\Mail\Transport\Storage which would utilize already implemented storages from Zend/Mail/Storage/*. I see Zend_Mail_Storage_Writable_Maildir currently implements Zend_Mail_Storage_Writable_Interface, the others may be tweaked same way probably, not went into much details about that yet.
Any comments on this one?
- DONE Milestone 1: Complete theory of operation
- Milestone 2: Define if some additional features are required (using feedback).
- Milestone 3: Documentation
|UC-01: Configuring the transport using Zend_Application_Resource_Mail|
This is how the configuration might be done in application.ini configuration file. This would make File mail transport the default transport for the development environment, while keeping regular smtp for the production:
|UC-02: Using a custom callback to generate file names|
To use a custom callback just pass a function that accepts the transport's instance as first parameter as 'callback' option to the \Zend\Mail\Transport\File constructor (or to setOptions method). In the use case below, callback utilizes default callback, but prepends the file name with the recipient email:
In the target folder a file with name like "firstname.lastname@example.org_ZendMail_1276322086_1871539247.tmp" appears and the content is