This marks the second in an on-going series on Zend_Form decorators.

You may have noticed in the previous installment that the decorator's render() method takes a single argument, $content. This is expected to be a string. render() will then take this string and decide to either replace it, append to it, or prepend it. This allows you to have a chain of decorators — which allows you to create decorators that render only a subset of the element's metadata, and then layer these decorators to build the full markup for the element.

Let's look at how this works in practice.

I've been seeing ranting and general confusion about Zend_Form decorators (as well as the occasional praises), and thought I'd do a mini-series of blog posts showing how they work.

I'm an unabashed Vim user. It has been my primary editor for over seven years now, when I switched to it to make it easier to edit files over SSH. At the time, I made myself use it exclusively for a month so that the habits would be ingrained, and took the time to go through vimtutor as well as to order and read Steve Oualline's Vim book. And when I say "exclusively," I mean it — I switched to using Mutt for email at that time, and also started doing all code development, outlining, and more in vim. And after a month, I realized I didn't want to use anything else.

Ironically, I find myself working for a company that sells an Integrated Development Environment (IDE). As a result, I've done some test runs with Eclipse, Zend Studio for Eclipse, and even NetBeans, to see what features they offer and to see if there would be anything compelling that might make me change my mind.

Being a technical presenter, I've often run up against the issue of how to present code snippets.

The easiest route is to simply cut-and-paste into your presentation software. However, such code is basically unreadable: it's hard to get indentation correct, and the lack of syntax highlighting makes them difficult to read (syntax highlighting helps users understand the purpose of the various language constructs).

I'm speaking at PHP Quebec this week. While I live a scant 1.5 hours away from the venue, this is the first I've been to the conference. The snow gods have declared their wrath already, but I plan to thwart them and drive up to Montreal this evening regardless.

I'm giving two talks and participating in a panel discussion this week. The first talk is entitled "Practical Zend Framework Jutsu with Dojo," and, while it may look like a familiar topic of mine by this point, I've spent the last several days reworking the talk entirely, and am very much looking forward to presenting it tomorrow. (My copy of "Presentation Zen" could not have come soon enough! and that's all I'll say about that.)

On Friday, PHP Quebec has introduced a "Framework Bootcamp" track, including sessions by myself, Fabien Potencier of symfony, and Derick Rethans representing eZ Components. My talk that day is entitled "Zend Framework Little Known Gems." While hardly a completely original talk (Aaron Wormus did a "Hidden Gems" series of posts for DevZone a couple years back, and Zend's own Shahar Evron did a similar talk at last fall's IPC), this will be my first time doing a Zend Framework talk on something other than the MVC stack (or how to use components with the MVC stack). Leaving my comfort zone, so to speak.

Towards the end of the day, Fabien, Derick, and myself will be corralled onstage together for a "Framework Comparison".

If you're headed up to PHP Quebec this week, I look forward to meeting you or seeing you again!

I ran into an issue recently with Dojo's ContentPanes. I was using them with a TabContainer, and had made them closable; however, user actions might re-open tabs that pull from the same source. This led to conflicts with dijit IDs that I had to resolve.

Most Dijits have a destroyRecursive() method which should, theoretically, destroy any dijits contained within them. However, for many Dijits, this functionality simply does not work due to how they are implemented; many do not actually have any knowledge of the dijits beneath them.

ContentPanes fall into this latter category. fortunately, it's relatively easy to accomplish, due to Dojo's heavily object oriented nature.

I've been doing a fair bit of programming in Dojo lately, and have on occasion run into either inconsistent interfaces, or interfaces that simply fail to load in Internet Explorer. Several people have pointed out to me some optimizations to make, but, being a lazy programmer, I often forget to do so.

Fortunately, there's a tool for lazy developers like myself: JSLint. Linters are commonly used in static development languages so that developers can verify that their programs are syntactically correct prior to compilation; they basically ensure that you're not accidentally attempting to compile something that will never compile in the first place. Many dynamic languages also have them; I've had a key bound in vim to run the current file through PHP's linter for many years now. JSLint provides linting capabilities for JavaScript, as well as some code analysis to point you towards some best practices — mainly geared for cross-browser compatability.

I use Linux on the desktop (currently Ubuntu), but occasionally need to use Windows for things like webinars, OS-specific testing, etc. I started using VirtualBox for virtualization around six months ago, and have been reasonably satisfied; Windows boots quickly, and everything "just works." That is, until yesterday.

I was given a linux VM image running a web server and some applications I needed to review. On top of that, I needed to do so over WebEx, so that I could share my screen with somebody else. This meant I needed the following to work:

1. Internet access for my Windows VM
2. Access to my linux VM from my Windows VM
3. Ideally, access to both guest VMs from my linux host
4. Ideally, internet access for my linux host

I'm really not sure I understand these "seven things" or "tagged" memes, but I'm going to give it a shot, after Keith Casey did a drive-by tagging of me on New Year's Eve.

So, without further ado, seven things you may not know about me…