For the past month, I've been immersed in PHP 5.3 as I and my team have started work on Zend Framework 2.0. PHP 5.3 offers a slew of new language features, many of which were developed to assist framework and library developers. Most of the time, these features are straight-forward, and you can simply use them; in other cases, however, we've run into behaviors that were unexpected. This post will detail several of these, so you either don't run into the same issues — or can capitalize on some of our discoveries.
One possibility presented to us was the possibility of utilizing GPG signing of commit messages. Unfortunately, I was able to find little to no information on the 'net about how this might be done, so I started to experiment with some solutions.
The approach I chose utilizes git hooks,
commit-msg hook client-side, and the
Brandon Savage approached me with an interesting issue regarding ZF bootstrap resources, and accessing them in your action controllers. Basically, he'd like to see any resource initialized by the bootstrap immediately available as simply a public member of his action controller.
So, for instance, if you were using the "DB" resource in your application, your
controller could access it via
I see a number of questions regularly about module bootstraps in Zend Framework, and decided it was time to write a post about them finally.
In Zend Framework 1.8.0, we added
Zend_Application, which is intended to (a)
formalize the bootstrapping process, and (b) make it re-usable. One aspect of
it was to allow bootstrapping of individual application modules — which are
discrete collections of controllers, views, and models.
The most common question I get regarding module bootstraps is:
Why are all module bootstraps run on every request, and not just the one for the requested module?
To answer that question, first I need to provide some background.
In previous articles, I've explored building service endpoints and RESTful services with Zend Framework. With RPC-style services, you get to cheat: the protocol dictates the content type (XML-RPC uses XML, JSON-RPC uses JSON, SOAP uses XML, etc.). With REST, however, you have to make choices: what serialization format will you support?
Why not support multiple formats?
There's no reason you can't re-use your RESTful web service to support multiple formats. Zend Framework and PHP have plenty of tools to assist you in responding to different format requests, so don't limit yourself. With a small amount of work, you can make your controllers format agnostic, and ensure that you respond appropriately to different requests.
This week, I've been attending Symfony Live in Paris, speaking on integrating Zend Framework with Symfony. The experience has been quite rewarding, and certainly eye-opening for many.
To be honest, I was a little worried about the conference — many see Symfony and ZF as being in competition, and that there would be no cross-pollination. I'm hoping that between Fabien, Stefan, and myself, we helped dispel that myth this week.
In my last article,
I wrote about how to get started with
Zend_Application, including some
information about how to write resource methods, as well as listing available
resource plugins. What happens when you need a re-usable resource for which
there is no existing plugin shipped? Why, write your own, of course!
All plugins in Zend Framework follow a common pattern. Basically, you group plugins under a common directory, with a common class prefix, and then notify the pluggable class of their location.
For this post, let's consider that you may want a resource plugin to do the following:
We added Zend_Application to Zend Framework starting in version 1.8.0. The intent behind the component was to formalize the application bootstrapping process, and provide a simplified, configuration-driven mechanism for it.
Zend_Application works in conjunction with
which, as you might guess from its name, is what really does the bulk of the
work for bootstrapping your application. It allows you to utilize plugin
bootstrap resources, or define local bootstrap resources as class methods. The
former allow for re-usability, and the latter for application-specific
initialization and configuration.
Zend_Application_Bootstrap provides for dependency tracking
(i.e., if one resource depends on another, you can ensure that that other
resource will be executed first), and acts as a repository for initialized
resources. This means that once a resource has been bootstrapped, you can
retrieve it later from the bootstrap itself.
When keeping tabs on your ZF applications, it's often difficult to separate application errors from general PHP errors, and if you aggregate them in the same location as your web server errors, this can become more difficult still.
Additionally, PHP's error reporting doesn't provide a ton of context, even when reporting uncaught exceptions — typically you'll only get a cryptic exception message, and what file and line emitted it.
Zend Server's Monitor extension has some capabilities for providing more context, and does much of this by default: request and environment settings available when the error was logged, the function name and arguments provided, and a full backtrace are available for you to inspect. Additionally, the Monitor extension includes an API that allows you to trigger custom Monitor events, and you can provide additional context when doing so — such as passing objects or arrays that may help provide context when debugging.
As a followup to my previous post, I now turn to RESTful web services. I originally encountered the term when attending php|tropics in 2005, where George Schlossnaggle likened it to simple GET and POST requests. Since then, the architectural style — and developer understanding of the architectural style — has improved a bit, and a more solid definition can be made.