Blog Posts
Why Conventions Matter
When I started teaching myself scripting languages, I started with Perl. One Perl motto is "TMTOWTDI" — "There's More Than One Way To Do It," and pronounced "tim-toady." The idea is that there's likely multiple ways to accomplish the very same thing, and the culture of the language encourages finding novel ways to do things.
I've seen this principle used everywhere and in just about every programming situation possible, applied to logical operations, naming conventions, formatting, and even project structure. Everyone has an opinion on these topics, and given free rein to implement as they see fit, it's rare that two developers will come up with the same conventions.
TMTOWTDI is an incredibly freeing and egalitarian principle.
Over the years, however, my love for TMTOWTDI has diminished some. Freeing as it is, is also a driving force behind having coding standards and conventions — because when everyone does it their own way, projects become quickly hard to maintain. Each person finds themselves reformatting code to their own standards, simply so they can read it and follow its flow.
Additionally, TMTOWTDI can actually be a foe of simple, elegant solutions.
Why do I claim this?
On Error Handling and Closures
The error suppression operator in PHP (@
) is often seen as a necessary evil.
Many, many low-level function will return a value indicating an error, but also
raise an E_NOTICE
or E_WARNING
— things you might be able to recover from,
or conditions where you may want to raise an exception.
So, at times, you find yourself writing code like this:
if (false === ($fh = @fopen($filename, 'r'))) {
throw new RuntimeException(sprintf(
'Could not open file "%s" to read', $filename
));
}
Seems straight-forward enough, right? But it's wrong on so many levels.
Getting started writing ZF2 modules
During ZendCon this year, we released 2.0.0beta1 of Zend Framework. The key story in the release is the creation of a new MVC layer, and to sweeten the story, the addition of a modular application architecture.
"Modular? What's that mean?" For ZF2, "modular" means that your application is built of one or more "modules". In a lexicon agreed upon during our IRC meetings, a module is a collection of code and other files that solves a specific atomic problem of the application or website.
As an example, consider a typical corporate website in a technical arena. You might have:
- A home page
- Product and other marketing pages
- Some forums
- A corporate blog
- A knowledge base/FAQ area
- Contact forms
These can be divided into discrete modules:
- A "pages" modules for the home page, product, and marketing pages
- A "forum" module
- A "blog" module
- An "faq" or "kb" module
- A "contact" module
Furthermore, if these are developed well and discretely, they can be re-used between different applications!
So, let's dive into ZF2 modules!
Using the ZF2 EventManager
Earlier this year, I wrote about Aspects, Intercepting Filters, Signal Slots, and Events, in order to compare these similar approaches to handling both asychronous programming as well as handling cross-cutting application concerns in a cohesive way.
I took the research I did for that article, and applied it to what was then a "SignalSlot" implementation within Zend Framework 2, and refactored that work into a new "EventManager" component. This article is intended to get you up and running with it.
Using DocBlox
Until a few years ago, there were basically two tools you could use to generate API documentation in PHP: phpDocumentor and Doxygen. phpDocumentor was long considered the standard, with Doxygen getting notice when more advanced features such as inheritance diagrams are required. However, phpDocumentor is practically unsupported at this time (though a small group of developers is working on a new version), and Doxygen has never had PHP as its primary concern. As such, a number of new projects are starting to emerge as replacements.
One of these is DocBlox. I am well aware there are several others — and indeed, I've tried several of them. This post is not here to debate the merits or demerits of this or other solutions; the intention is to introduce you to DocBlox so that you can evaluate it yourself.
Converting DocBook4 to DocBook5
Within the Zend Framework 2 repository,
I recently performed a conversion from DocBook 4 to 5.
The latter is a more modern version of the toolchain, and offers a somewhat
simpler syntax and workflow. For example, you no longer need to track how many
levels deep you are in your chapter sections — you simply use a <section>
tag.
One of the nicer changes is that you do not need to specify a doctype any more;
you simply declare XML namespaces on your root elements and continue merrily on
your way. This actually allows us to remove some actions in our build process,
and makes validation much simpler.
Interestingly, for DocBook5 being available in beta since 2005 and an official standard since 2009, there is very little material on migrating from DocBook 4 to 5.
Proxies in PHP
A number of programming design patterns look very similar. One of these is the Proxy pattern, which, at first glance, can look like a number of others: Decorator, Flyweight, even plain old object extension. However, it has its own niche, and it can provide some incredible flexibility for a number of programming scenarios.
Backported ZF2 Autoloaders
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."
Code Generation with Zend\CodeGenerator
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.
Dependency Injection: An analogy
I've been working on a proposal for including service locators and dependency injection containers in Zend Framework 2.0, and one issue I've had is trying to explain the basic concept to developers unfamiliar with the concepts — or with pre-conceptions that diverge from the use cases I'm proposing.
In talking with my wife about it a week or two ago, I realized that I needed an analogy she could understand; I was basically using her as my rubber duck. And it turned out to be a great idea, as it gave me some good analogies.