Matthew Weier O'Phinney as a new post to his blog today looking at a few "do's" and "dont's" when it comes to working with module boostraps in your Zend Framework applications - an apparently somewhat confusing topic for several developers out there.

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.

He talks briefly about why module boostraps are run on every request (getting into some detail on Zend_Application), how you can properly set up your boostrapping process and how you can use plugins to initialize only the things you might need and, as he openly admits, that there's just not a really good way to handle this sort of module funcionality.

In a new post to his blog Matthew Weier O'Phinney looks at creating reusable plugins for the Zend_Application component of the Zend Framework. This is a follow-up from his previous article introducing Zend_Application.

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.

His example shows a plugin that can set the doctype of the view you're using and set the default page title and the separator. He mentions things like the framework's coding/naming standards, dependency tracking, setting up the configuration and, finally, doing the two actions laid out at the start. A few simple lines added to the application.ini file and you're all set to start using the new plugin.

Matthew Weier O'Phinney has a recent post to his blog giving a quick introduction to the Zend_Application component of the Zend Framework and how it can be used to create custom resources.

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. [...] 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.

Matthew gets right into the code, looking at how to create a simple bootstrap (for the "zf" command line tool to make the project) and the contents of the application.ini file. From there he looks at creating resources - bits of code that can be executed as a part of your bootstrapping process. His example shows the implementation of "_initCurrency" and "_initRegistry" methods.

Pablo Viquez has written up a mini-tutorial on getting your Zend Framework application's errors to log out to the Firebug panel (from the extension) with the help of FirePHP and Zend_Log.

I wanted to enable logging of exceptions to my PHP log file and also display them using FireBug. On a standard setup of Zend Framework, the Zend error handler plugin (Zend_Controller_Plugin_ErrorHandler) enable by default [...] I wanted to keep using the error handler plugin and didn't want to log the exceptions by using: Zend_Controller_Front::throwExceptions() or Zend_Controller_Response_Abstract::renderExceptions() or any other way since eventually might get complicated, besides, I think that the error handler plugin works fine and if it gets updated in the future, I won't have to do a major refactor.

He shows how to create the Zend_Log object to write out on the development system (based on the ini setting for the Zend Framework application), how to use it to send the log message out to the waiting client. Examples of the output - a screenshot of the Firebug panel and the error log output.

The latest version of the Zend Framework has officially been released - version 1.8, the first in the 1.8.x series with lots of new features including components encouraging the rapid application development functionality the framework already has and additional features to make it easier to use ZF in "the cloud".

I'm pleased to announce the Zend Framework 1.8.0 release, the first in our 1.8 series of releases. This release marks the culmination of several long-standing projects, as well as a formalization of many of our recommended practices.

The new rapid application development features include something that's been a long time coming, Zend_Tool. It gives you a command-line interface to build out ZF project parts and configure/display settings for them. Zend_Application was also released in relation to provide a standardized way for boostraping applications with either default configurations or custom settings.

Since cloud computing use has been on the rise, the ZF development team has added in two new components - interfaces for Amazon's Simple Storage Service and the Elastic Compute Cloud.

You can read more in the official press release from Zend.

Rob Allen has a new post with a few introductory notes about the upcoming Zend_Application component of the Zend Framework that's coming and (if all goes well) will be deployed with the 1.8 version of the framework.

Zend_Application is now in the incubator and being actively developed for version 1.8 of Zend Framework. I've had a little play using it with a standard ZF application with no modules and this is what I've worked out so far. [...] Zend_Application is intended to make bootstrapping your application easier, presumably with less code.

He looks specifically at the bootstraping aspect of the component and comes up with an example Bootstrap.php file that sets up a configuration, a database resource, a view object and the location and information for the front controller. Another boostrap example shows how you can use a configuration file to do it similarly but more flexibly.