In the past six weeks, I've delivered both a webinar and a tutorial on Zend Framework 2 development patterns. The first pattern I've explored is our new suite of autoloaders, which are aimed at both performance and rapid application development — the latter has always been true, as we've followed PEAR standards, but the former has been elusive within the 1.X series.

Interestingly, I've had quite some number of folks ask if they can use the new autoloaders in their Zend Framework 1 development. The short answer is "yes," assuming you're running PHP 5.3 already. If not, however, until today, the answer has been "no."

Zend Framework has offerred a code generation component since version 1.8, when we started shipping Zend_Tool. Zend_CodeGenerator largely mimics PHP's Reflection API, but does the opposite: it instead generates code.

Why might you want to generate code?

• You can use it as an assistive form of "copy and paste" for common tasks (as an example, it's used in zf.sh to generate controller classes and action methods).
• You might want to generate code from configuration, to remove the "compile" phase of generating objects from configuration values. This is often done to improve performance in situations that rely heavily on configurable values.

Zend\CodeGenerator in the ZF2 repository is largely ported from Zend Framework 1, but also includes some functionality surrounding namespace usage and imports. I used it this week when working on some prototypes, and found it useful enough that I want to share some of what I've learned.

ZF2 development is ramping up. We've been at it for some time now, but mostly taking care of infrastructure: converting to namespaces, re-working our exception strategy, improving our test suites, and improving our autoloading and plugin loading strategies to be more performant and flexible. Today, we're actively working on the MVC milestone, which we expect to be one of the last major pieces necessary for developers to start developing on top of ZF2.

A question I receive often is: "How can I contribute to ZF2?"

Consider this your guide.

Last month, during PHP Advent, gwoo wrote an interesting post on Aspect-Oriented Design, or Aspect Oriented Programming (AOP) as it is more commonly known. The article got me to thinking, and revisiting what I know about AOP, Intercepting Filters, and Signal Slots -- in particular, what use cases I see for them, what the state of current PHP offerings are, and where the future may lie.

But first, some background is probably in order, as this is a jargon-heavy post.

My job is great: I get to play with technology and code most days. My job is also hard: how does one balance both functionality and usability in programming interfaces?

I've been working, with Ralph Schindler, on a set of proposals around the Zend Framework 2.0 MVC layer, specifically the "C", or "Controller" portion of the triad. There are a ton of requirements we're trying to juggle, from making the code approachable to newcomers all the way to making the code as extensible as possible for the radical performance tuning developers out there.

In Zend Framework 2.0, we're refactoring in a number of areas in order to increase the consistency of the framework. One area we identified early is how plugins are loaded.

The word "plugins" in Zend Framework applies to a number of items:

• Helpers (view helpers, action helpers)
• Application resources
• Filters and validators (particularly when applied to Zend_Filter_Input and Zend_Form)
• Adapters

In practically every case, we use a "short name" to name the plugin, in order to allow loading it dynamically. This allows more concise code, as well as the ability to configure the code in order to allow specifying alternate implementations.

As I write this, ZendCon begins in less than a week. I have the honor and pleasure to be speaking there again, for the sixth year running.

I had a twitter/IRC exchange yesterday with Andries Seutens and Nick Belhomme regarding applications that include widgets within their layout. During the exchange, I told Andriess not to use the action() view helper, and both Andriess and Nick then asked how to implement widgets if they shouldn't use that helper. While I ended up having an IRC exchange with Nick to give him a general idea on how to accomplish the task, I decided a longer writeup was in order.

During the past week, I've been looking at different strategies for autoloading in Zend Framework. I've suspected for some time that our class loading strategy might be one source of performance degradation, and wanted to research some different approaches, and compare performance.

In this post, I'll outline the approaches I've tried, the benchmarking stategy I applied, and the results of benchmarking each approach.