Yesterday, I released the Release Candidate number 1 of SlmMail. SlmMail provides API implementations of the largest email service providers. So if your sendmail or SMTP fails, include SlmMail and offload the risk of sending emails to others. In the last years, emails must be secured with all kind of mechanisms like SPF, DKIM and DMARC. It just costs a lot of time and knowledge to maintain your email stack, so that's why email service providers comes to help.
SlmMail has implemented the API of various of the largest players in the field:
- AlphaMail
- Amazon SES
- Elastic Email
- Mailgun
- Mandrill
- Postmark
- Postage
- Send Grid
The main benefit of SlmMail is these integrations are possible without any modification to your message objects or service layer! If you handled the transport with dependency injection (as you should do!), then you simply inject another Transport implementation. And guess, it works out of the box.
After using Zend Framework 2 for more than a year, I just found out about strategies for hydrators today. Yes, today and thanks to Michaël Gallego who introduced me to this concept. But I think many people underestimate what they can do with hydrators and their strategies, so this post explains why strategies for hydrators are awesome.
Take an entity for example which contains a timestamp. You prefer to type hint on the setter for a DateTime object, for obvious reasons:
public function getDate()
{
return $this->timestamp;
}
public function setDate(DateTime $timestamp)
{
$this->timestamp = $timestamp;
return $this;
}
However, you run into troubles if you bind this entity to a form. By default the POST contains string values, so a date value can be send to the server as "2012-11-06". The hydrator wants to set this string to your entity, but it fails due to the missing DateTime object. And then the strategy comes to the rescue!
Many components in Zend Framework 2 following the adapter or plugin pattern, make use of the Zend\ServiceManager\AbstractPluginManager. The abstract plugin manager is a service locator implementation which allows to define services as invokable or with factories. Many of these plugin managers are loaded automatically (see for example my earlier post about service managers). However, the manager for loaders of Zend\I18n\Translator is a stranger in our midst.
As of an IRC conversation today on #zftalk I, with a few others, found out how the plugin manager of Zend\I18n\Translator works. On the outside, it is an implementation of the abstract plugin manager. But if you look more closely, the plugin manager has no "parent" service locator. That means, if you have defined a reposity or service you need inside a loader, you don't have access to it!
In this blog post I will show how to fix this with an example loader, a database loader based on the EntityManager of Doctrine.
Today we at Soflomo released Soflomo\Prototype, a new Zend Framework 2 module. The module is just in use for about a couple of hours, but it already saves us so much work, we would like to share it. It is available under the New BSD (3 clause) license, feel free to use it!
The goal is to make it extremely easy inside Zend Framework 2 to start prototyping html pages. Designers and frontend developers currently often have to wait for a Zend Framework 2 developer to create a couple of routes, link them to a controller, assign the right view script and enable this all in a module. With Soflomo\Prototype, you simply say url /foo/bar must render /foo/bar.phtml. Nothing more.
The Zend\ServiceManager is a component which handles (besides other stuff) dependency injection. During the developments of Zend Framework 2 I have looked at dependency injection thoroughly. A good resource is from Martin Fowler, where he explains there are three types of dependency injection. In this post I am particularly interested in injecting soft dependencies with interface injection.
The help of the Zend\ServiceManager makes it straightforward to have decoupled objects. For the use cases where you have a soft dependency, the ServiceManager has a great tool called initializers. Initializers are small "callables" providing add-on features for your objects you pull from the service manager.