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:

• Set the view doctype
• Set the default page title and title separator

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 Zend_Application_Bootstrap, 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.

Additionally, 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.

The hubbub surrounding "Web 2.0" is around sharing data. In the early iterations, the focus was on "mashups" -- consuming existing public APIs in order to mix and match data in unique ways. Now, more often than not, I'm hearing more about exposing services for others to consume. Zend Framework makes this latter trivially easy via its various server classes.

It's probably already a foregone conclusion, but I'm speaking once again at ZendCon this year -- one week from today!

My good friend, Keith Casey, is once again chairing Zendcon's UnCon. For those who have never attended, it's basically one or more tracks running parallel to the main conference, but with content pitched by attendees -- sometimes presented by them, other times presented by others who are knowledgeable in the field.

Why should you care? There are great sessions already selected for the conference featuring some well-known speakers from the PHP world; why would you want to either attend or present at the uncon?

Today is the kickoff for CodeWorks 2009, a remarkable PHP road show hitting seven cities in 14 days. While I'm not joining the tour until Atlanta, I'm proud to be joining up at that stop and presenting a Zend Framework tutorial during the tour.

I've been using NetworkManager for some time now, and appreciate how easy it makes both connecting to wifi as well as VPNs. That said, I've had an issue with it that I only resolved today.

When working from home, I prefer to use a VPN split tunnel setup -- I'm behind a firewall all the time, and it's useful to be able to run virtual machines while still connected to my VPN (e.g., when doing training or webinar sessions). However, I noticed some months ago that this wasn't working. I assumed at first it was a change in our network setup, but others reported that the split tunnel was working fine. It's been particularly problematic when on IRC -- if the VPN drops, I lose my IRC connection, meaning I have to re-connect and re-claim my nick.

So, I did some searching, and found an interesting setting. In NetworkManager, "Configure..." then "Edit" your VPN connection, and navigate to the "IPv4 Settings" tab. Once there, click the button that says "Routes..." and select the checkbox next to "Use this connection only for resources on its network". Press Ok to close the dialog, then "Apply" to exit out of the VPN configuration. Re-connect to the VPN, and you should be all set.

Note: this will only work if your VPN server is configured to allow split tunnels. Additionally, only do so if you are behind a firewall. Practice safe networking.

I've been using Git for around a year now. My interest in it originally was to act as a replacement for SVK, with which I'd had some bad experiences (when things go wrong with svk, they go very wrong). Why was I using a distributed version control system, though?

Several people have pointed out to me recently that I haven't blogged since early May, prior to attending php|tek. Since then, I've built up a huge backlog of blog entries, but had zero time to write any of them.

The backlog and lack of time has an easy explanation: my change of roles from Architect to Project Lead on the Zend Framework team. While the change is a welcome one, it's also been much more demanding on my time than I could have possibly envisioned. Out of the gate, I had to finish up the 1.8 release, and move immediately into planning and execution of the 1.9 release -- while learning the ropes of my new position, and continuing some of my previous development duties. Add a couple of conferences (php|tek and DPC) into the mix, and you can begin to see the issues.

A number of people on the mailing list and twitter recently have asked how to autoload Doctrine using Zend Framework's autoloader, as well as how to autoload Doctrine models you've created. Having done a few projects using Doctrine recently, I can actually give an answer.

The short answer: just attach it to Zend_Loader_Autoloader.

Now for the details.