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:
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
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.
I'm currently doing research and prototyping for autoloading alternatives in
Zend Framework 2.0. One approach I'm looking at
involves creating explicit class/file maps; these tend to be much faster than
include_path, but do require some additional setup.
My algorithm for generating the maps was absurdly simple:
The question was what implementation approach to use.
I'm well aware of
RecursiveDirectoryIterator, and planned to use that.
However, I also had heard of
FilterIterator, and wondered if I could tie that
in somehow. In the end, I could, but the solution was non-obvious.
Because we're in full throes of Zend Framework 2.0 development, I find myself with a variety of PHP binaries floating around my system from both the PHP 5.2 and 5.3 release series. We're at a point now where I'm wanting to test migrating applications from ZF 1.X to 2.0 to se see what works and what doesn't. But that means I need more than one PHP binary enabled on my server…
I use Zend Server on my development box; it's easy to install, and uses my native Ubuntu update manager to get updates. On Ubuntu, it installs the Debian Apache2 packages, so I get the added bonus of familiarity with the configuration structure.
I installed Zend Server some time ago, so I'm still on a PHP 5.2
binary. I have several PHP 5.3 binaries compiled and installed locally for
running unit tests and sample scripts already — so the question was how to keep
mod_php running while simultaneously allowing the ability to run
selected vhosts in 5.3?
The answer can be summed up in one acronym: FastCGI.
When I was at Symfony Live this past February, I assisted Stefan Koopmanschap in a full-day workshop on integrating Zend Framework in Symfony applications. During that workshop, Stefan demonstrated creating Symfony "tasks". These are classes that tie in to the Symfony command-line tooling — basically allowing you to tie in to the CLI tool in order to create cronjobs, migration scripts, etc.
Of course, Zend Framework has an analogue to Symfony tasks in the Zend_Tool component's "providers". In this post, I'll demonstrate how you can create a simple provider that will return the most recent entry from an RSS or Atom feed.
The past few months have kept myself and my team quite busy, as we've turned our attentions from maintenance of the Zend Framework 1.X series to Zend Framework 2.0. I've been fielding questions regularly about ZF2 lately, and felt it was time to talk about the roadmap for ZF2, what we've done so far, and how the community can help.
I've been hearing about and reading about Gearman for a couple years now, but, due to the nature of my work, it's never really been something I needed to investigate; when you're writing backend code, scalability is something you leave to the end-users, right?
Wrong! But perhaps an explanation is in order.
For the third year running, I'm pleased to be speaking at the Dutch PHP Conference, held again in Amsterdam this coming 10–12 of June.