Enrico just returned from phpDay, where he spoke about Expressive and the upcoming Zend Framework 3. One piece of feedback he brought back had to do with how people perceive they should be building Expressive applications: many think, based on our examples, that it's completely configuration driven!
As it turns out, this is far from the truth; we developed our API to mimic that of traditional microframeworks, and then built a configuration layer on top of that to allow making substitutions. However, it's not only possible, but quite fun, to mix and match the two ideas!
A month or two ago, we pushed a new release of zend-mvc that provides a number of forwards-compatibility features to help users prepare their applications for the upcoming v3 release.
One of those was, evidently, quite controversial: in v3, zend-servicemanager no
longer defines the
ServiceLocatorAwareInterface, and this particular release
of zend-mvc raises deprecation notices when you attempt to inject a service
locator into application services, or pull a service locator within your
The arguments go something like this:
These are usually followed by folks:
So, I've decided to do the last, justify the change, which addresses the reasons
why we won't do the middle two, and addresses why the assumptions and assertions
ServiceLocatorAware's usefulness are mostly misguided.
Today we accomplished one of the major goals towards Zend Framework 3: splitting the various components into their own repositories. This proved to be a huge challenge, due to the amount of history in our repository (the git repository has history going back to 2009, around the time ZF 1.8 was released!), and the goals we had for what component repositories should look like. This is the story of how we made it happen.
A few days ago, we released our first beta of Apigility. We've started our documentation effort now, and one question has arisen a few times that I want to address: How can you use Hypermedia Application Language (HAL) in RPC services?
In this post, I'll be covering documenting your API — techniques you can use to indicate what HTTP operations are allowed, as well as convey the full documentation on what endpoints are available, what they accept, and what you can expect them to return.
While I will continue covering general aspects of RESTful APIs in this post, I will also finally introduce several ZF2-specific techniques.
In my last post, I covered some background on REST and the Richardson Maturity Model, and some emerging standards around hypermedia APIs in JSON; in particular, I outlined aspects of Hypermedia Application Language (HAL), and how it can be used to define a generic structure for JSON resources.
In this post, I cover an aspect of RESTful APIs that's often overlooked: reporting problems.
RESTful APIs have been an interest of mine for a couple of years, but due to circumstances, I've not had much chance to work with them in any meaningful fashion until recently.
Rob Allen and I proposed a workshop for PHP Benelux 2013 covering RESTful APIs with ZF2. When it was accepted, it gave me the perfect opportunity to dive in and start putting the various pieces together.
One of the exciting features of the newly released Zend Framework 2 is the new module system.
While ZF1 had modules, they were difficult to manage. All resources for all modules were initialized on each request, and bootstrapping modules was an onerous task. Due to the difficulties, modules were never truly "plug-and-play", and thus no ecosystem ever evolved for sharing modules.
In Zend Framework 2, we've architected the MVC from the ground up to make modular applications as easy as possible. Within ZF2, the MVC simply cares about events and services — and controllers are simply one kind of service. As such, modules are primarily about telling the MVC about services and wiring event listeners.
To give you an example, in this tutorial, I'll show you how to install the Zend Framework 2 skeleton application, and we'll then install a module and see how easy it is to add it to the application and then configure it.
I think there are some really good ideas that have come out of this, and also a number of questionable practices1.
One piece in particular I've focussed on is the concept of so-called “microframeworks”.
In Zend Framework 1, controller's had an
init() method, which was called
after the controller was instantiated. The reason for it was to encourage
developers not to override the constructor, and thus potentially break some of
the functionality (as a number of objects were injected via the constructor).
init() was useful for doing additional object initialization.
class MyController extends Zend_Controller_Action
public function init()
// do some stuff!
But this feature is missing from ZF2; how can we accomplish this sort of pattern?