Update: this article is now available in French, courtesy of Frédéric Blanc.

I've fielded a number of questions from people wanting to know how to handle authentication and identity persistence in Zend Framework. The typical issue is that they're unsure how to combine:

• An authentication adapter
• A login form
• A controller for login/logout actions
• Checking for an authenticated user in subsequent requests

It's not terribly difficult, but it does require knowing how the various pieces of the MVC fit together, and how to use Zend_Auth. Let's take a look.

I use Vim for all my editing needs — TODO lists, email, presentation outlines, coding in any language… everything. So, I thought I'd start sharing some of my vim habits and tools with others, particularly those that pertain to using Vim with PHP.

Somebody asked for some examples of how I use the headLink(), headScript(), and other placeholder helpers, so I thought I'd take a crack at that today.

First off, let's look at what these helpers do. Each are concrete instances of a placeholder. In Zend Framework, placeholders are used for a number of purposes:

• Doctype awareness
• Aggregation and formatting of aggregated content
• Capturing content
• Persistence of content between view scripts and layout scripts

Let's look at these in detail.

As many know, Zend Framework 1.5.0 is almost ready for release… heck, it might even be released by the time you read this. There are a ton of new features worth looking into, but I'll list some of my own favorites here - the ones I've been either working on or using.

Full disclosure: I am employed by Zend to program Zend Framework. That said, the following is all my opinion, and is based on my experiences with Zend Framework, as well as answering questions on a variety of mailing lists and with other OSS projects (PEAR, Solar, and Cgiapp in particular).

One of my biggest pet peeves in the OSS world is vague bug/issue reports and feature requests. I cannot count the number of times I've seen a report similar to the following:

<Feature X> doesn't work; you need to fix it now!

If such a report comes in on an issue tracker, it's invariably marked critical and high priority.

What bothers me about it? Simply this: it gives those responsible for maintaining Feature X absolutely no information to work on: what result they received, what was expected, or how exactly they were using the feature. The reviewer now has to go into one or more cycles with the reporter fishing for that information — wasting everyone's time and energy.

Only slightly better are these reports:

<Feature X> doesn't work — I keep getting <Result X> from it, which is incorrect.

At least this tells the reviewers what they reporter is receiving… but it doesn't tell them how they got there, or what they're expecting.

So, the following should be your mantra when reporting issues or making feature requests:

• What is the minimum code necessary to reproduce the issue or show the desired API?
• What is the expected result?
• What is the actual result?

Just an FYI for anyone interested: I'll be performing a webinar for this week's Zend Wednesday Webinar series on Zend_Form. You can get details on the webinar and how to register for it at the Zend_Form webinar information page.

I'll be covering the design of Zend_Form, the basic usage and various classes and plugins available, and internationalization of your forms. Please join me Wednesday at noon EST!

I've been working on Zend_Form for the past few weeks, and it's nearing release readiness. There are a number of features that Cal didn't cover in his DevZone coverage (in part because some of them weren't yet complete) that I'd like to showcase, including:

• Internationalization
• Element grouping for display and logistical purposes
• Array support

This post will serve primarily as a high-level overview of some of these features; if you're looking for more in-depth coverage, please review the unit tests. :-)

Ivo already pointed this out, but I want to point it out again: Boy Baukema writes a very nice entry regarding backwards compatibility on the ibuildings.nl corporate blog.

Backwards compatibility (BC) is a tricky thing to support, even when you strive hard to, as Boy puts it, "think hard about your API" prior to release. Somebody will always come along and point out ways it could have been done better or ways it could be improved. I've had to wrestle with these issues a ton since joining the Zend Framework team, and while it often feels like the wrong thing to do to tell somebody, "too little, too late" when they have genuinely good feedback for you, its often in the best interest of the many users already using a component.

I had the pleasure of meeting Boy last year when visiting the ibuildings.nl offices, and he's got a good head on his shoulders. He does a nice job outlining the issues and a number of approaches to BC; if you develop a project for public consumption, you should definitely head over and read what he has to say.

The Burlington PHP User Group is having another meeting tonight at 5:30pm at Brown & Jenkins Coffee Roasters. From the announcement:

Bradley Holt will be giving a presentation on developing a web application using Zend Framework. Bradley Holt is founder and web developer for Found Line, a local design and development studio which has used Zend Framework in several recent projects. He also works as a software developer for a local non-profit. Before starting Found Line he worked as computer trainer teaching a variety of subjects including Java/JSP, ASP.NET, and PHP

Visit the meeting page for details on location and RSVPs. If you're in the Burlington, VT, area, we'd love to see you there!