At the time of Zend_Tool's initial release, the standard application structure you are familiar with today was just being released as well with Zend_Application. In addition, the testing controllers from this newly standardized application layer, were too, in their infancy. [...] Recently, while Sebastian Bergmann was working on his pet project php-project-wizard, he noticed a few inconsistencies with the stubs that Zend_Tool was generating and decided to send us some recommendations on how to best leverage PHPUnit 3.4+ to test our application's assets.

He walks you through a newly generated project and shows (complete with screenshots) some of the updates that have been made like the new single bootstrap.php file, an updated phpunit.xml, a sample IndexController test and a bit of detail on what the generated tests actually look like.

I've started playing with the development versions of ZF 2.0 and one of the first things I thought I'd do was to port Akrabat_Db_Schema_Manager. It turned out to be reasonably easy. All I needed to do was rework my use of ZF components to use the new ZF2 ones. Whilst I was at it, I also converted it to use namespaces. I also had to reorganise the http://github.com/akrabat/Akrabat library so that I could have ZF1 and ZF2 code in it.

He includes "before" and "after" snippets of code to help illustrate the example. He had to change up things just a bit to handle the namespaces because of naming issues (a class named "Abstract" isn't allowed). If you want to see more of the updated code, you can check out his account on github with the changes.

If you want to play with the development versions of Zend Framework 2.0, then it's handy to be able to create ZF2 projects using the ZendTool command line tool. Rather unhelpfully, ZF2's ZendTool uses the same ini file (~/.zf.ini) as ZF1's Zend_Tool and the same zf.sh script filename, so you can't just put zf2 on to your path and it'll all just work. I am assuming that you're like me and have production sites using ZF1, so you probably don't want to mess up your current zf.sh usage. This is how I implemented side-by-side ZF cli scripts.

His is a three step process that involves the install of a copy of the Zend Framework 2 somewhere on your system, creating a new ini file for it and create a new bash script (called "zf2") that defines the new ini file location as a command line variable.

During [a workshop at Symfony Live] 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.

He shows how to create a sample provider - one that grabs data from two RSS feeds and outputs them - complete with code example, adding the provider someplace where Zend_Tool can find it and using the provider through the command-line "zf" tool.

This video uses a collection of powerful PHP libraries in order to illustrate how easy it really is to build a command-line tool for reporting against XML files. We start off by logging visitor statistics in the controller into a log file with Zend_Log. Once data has been collected, we're then able to utilize SimpleXML, Zend_Date and the Zend_Tool component to build out a very simple reporting tool.

He suggests one possible use is to create a cron job that will regenerate the reports nightly. You can view the screencast in the post or download a copy of the project to get started right away.

This screencast should help you setup Zend_Tool in your Zend Framework application. Zend_Tool is a command line entry point into your application. [...] The goal of this video is to start looking at how we can generate our own Manifest and Provider classes so that custom command line tools can be integrated into the Zend Framework application.

You can watch the screencast on the in-page player and can get a copy of the code from the project's repository.

One of the cool things about Zend Framework is it's cli tool, Zend_Tool. (zf) When zf works, it's awesome. However, when it breaks, it's a real pain in the butt. [...] Even though it's made great strides, setting up zf is still not seamless. To that end, here is my list of steps needed to setup zf.

He's using XAMPP on a Windows 7 machine and has a list of eight steps you'll need to follow to get Zend_Tool playing happily including locating certain directories (your general path, the path to your php.exe) and a few commands to tell the Zend Framework where to correctly deposit its files. If all goes well, you'll get this kind of result (screenshot). He mentions a slight problem, though - defining your own providers and them not being recognized. It can be corrected, though, using this handy tip.

I tinkered with the just recently discovered MongoDb and hooked it into the Zend_Log environment by creating a dedicated Zend_Log_Writer. The following post will therefore present a peek at a prototypesque implementation of this writer and show how the afterwards accumulated log entries can be accessed and filtered with a custom Zend_Tool project provider.

He extends the Zend_Log_Writer class to create the interface for the MongoDb and uses the mongo interface for PHP to bridge the gap. The application's INI file and Bootstrap are then modified to add in this new functionality and some example usage code is created both with and without the Zend_Tool tool.

The main point is, somewhere between the last time I tried it and this version, they refactored the suck out of it, which is great. It's now a useful tool. How useful remains to be seen but for the moment, I am cautiously optimistic. [...] So I'm posting there here, mainly for me because I'll forget them tomorrow if I don't, and for you if it can save you a few minutes of frustration.

He mentions weird happenings with include paths, how the tool's default setting is "production" and the work that the Zend Framework team needs to put into the Zend_Tool documentation to bring it up to the high mark a lot of the rest of the manual has hit.

Working on a project involving several legacy data migration tasks, I got curious what the Zend_Tool_Project component of the Zend Framework offers to create project specific providers for the above mentioned tasks or ones of similar nature. Therefore the following post will try to show how these providers can be developed in an iterative manner by scaffolding them via the capabilities of the Zend_Tool_Project ProjectProvider provider, enlived with action/task logic, and be used in the project scope.

He includes sample code and commands to build out the "project-provider" and how to make them "pretendable". You can see the results by issuing the "zf" command and seeing how the example methods (import-specials, export-specials) are now integrated as a part of the tool's functionality.