This past Wednesday, Zend's Chief Marketing Officer, Mark de Visser, and myself joined the NYPHP group for a special event meeting. Mark presented information on Zend's development stack and toolset (which I entirely missed, as I was still in transit), and I came in to give an overview of Zend Framework.

There were some great questions, and nice discussions following the event. If you live in New York and do PHP for a living, and haven't attended, you should; if you're ever visiting the area, see if you can attend a meeting!

Here are the slides. They're done using S5, a browser-based slideshow system. Simply unzip and double-click on index.html to start viewing.

Over the past few evenings, I've refactored File_Fortune to have it implement Iterator, Countable, and ArrayAccess — basically allowing it to act like an array for most intents and purposes. As a result, I've eliminated the need for the File_Fortune_Writer package, and greatly simplified the usage.

(Note: sure, File_Fortune may not be that big of a deal, but over 1000 downloads in the past two years indicates somebody is using it. Plus, it powers the random quotes on the family website. :-) )

As some examples:

require_once 'File/Fortune.php';

// Initialize and point it to a directory of fortunes
$fortunes = new File_Fortune('/path/to/fortunedir');

// Retrieve a random fortune 
// (works with either a directory or a single fortune file)
echo $fortunes->getRandom();

// Set to a specific fortune file:
$fortunes->setFile('myfortunes');

// Loop through and print all fortunes
foreach ($fortunes as $fortune) {
    echo str_repeat('-', 72), "\n", $fortune, "\n\n";
}

// Hmmm.. let's change one:
$fortunes[7] = "I never really liked that fortune anyways.";

// No need to explicitly save, as it's done during __destruct(), 
// but if you really want to:
$fortunes->save();

// Let's add a new fortune:
$fortunes->add('This is a shiny new fortune!');

// and now we'll verify it exists:
$index = count($fortunes) - 1;
echo $fortunes[$index];

All-in-all, it's a much better interface. Lesson learned: when porting code from other languages, it pays to take some time and determine if there might be a better API in your own.

In upcoming releases, I hope to modify the backend to use PHP's Streams API instead of direct file access, and also to allow providing a list of fortune files explicitly. After that, I should be ready for the initial stable release.

Update (2007-07-10): fixed parse error in examples

Update: Sara has pointed out a flaw in my last case. The file loadFileWithGlobals.php was incorrectly loading the wrong file — it should be loading withGlobals2.php (updated now). When it does, access to baz2 works as it should.

As I note to in my comment, however, I stand by my original rant: relying on globals for your applications is a bad practice, as it makes them difficult to integrate with other applications later. Developers using your application should not need to hunt down exactly when a global is first declared and explicitly push it into the global scope in order to get that application to integrate with others. Use other means, such as singletons or registries, to persist configuration within your applications.

In my last entry, I evidently greatly simplified the issue to the point that my example actually didn't display the behaviour I had observed. I'm going to show a more detailed example that shows exactly the behaviour that was causing issues for me.

First off, this has specifically to do with including files from within functions or class methods that then call on other files that define values in the global scope. In the original example, I show an action controller method that includes the serendipity bootstrap file, which in turn loads a configuration file that sets a multi-dimensional array variable in the global scope. Without first defining the variable in the global scope, this method of running serendipity fails.

Now, for the examples.

Update: I evidently simplified the issue too much, and have had several people rightly comment on the bogosity of the issue. However, there are still situations where $GLOBALS does not act as expected, and I outline these in my next entry.

In my previous entry, I ranted about the use of globals in popular PHP applications, and how they make embedding said applications difficult. I develop using object-oriented practices, and can honestly say I can't recall ever having slung a global variable around in my own code. Globals seem hackish to me, and as a result, trying to get applications that use them to behave correctly has been a challenge.

One of the applications I had in mind was Serendipity, the software that powers this blog. I was attempting to create a Zend Framework action controller that wraps my s9y instance so that I can do things such as apply ACLs from my website to selected entries, as well as pull the sitewide skeleton out from s9y so that I only have to maintain one version of it (I had one version for s9y, and another for my own content featured on the site (resume, contact form, etc.).

I tried importing the various config files into my action method prior to invoking the actual s9y bootstrap, but no dice. I also tried modifying the s9y config files to use the notation $GLOBALS['serendipity'] around the serendipity configuration variables (s9y uses a single multi-dimensional array for all configuration options). This didn't work, either; s9y functions that called global $serendipity were still getting a null value.

So, I did a little closer reading in the manual section on predefined variables, I discovered something interesting in the description of $GLOBALS (emphasis mine):

Contains a reference to every variable which is currently available within the global scope of the script.

Interestingly, the section on variable scope didn't make this distinction at all. Basically, if the variable you reference via $GLOBALS does not already exist, assigning it does nothing. It doesn't even raise a notice. It just silently goes ahead, leaving you thinking you set a new global variable, but in fact, you cannot assign new globals via $GLOBALS; you can only modify existing variables in the global scope.

So, I got around the issue by putting this in my front controller bootstrap:

$serendipity = null;

After that, I was able to create a wrapper action controller for s9y very easily:

/** Zend_Controller_Action */
require_once 'Zend/Controller/Action.php';

/**
 * Serendipity integration
 * 
 * @uses       Zend_Controller_Action
  */
class S9y_IndexController extends Zend_Controller_Action
{
    public function init()
    {
        // New ViewRenderer helper in ZF incubator; telling it not
        // to autorender a view script when done
        $this->_helper->viewRenderer->initView(null, null, array('noRender' => true));
    }

    public function indexAction()
    {
        global $serendipity;
        chdir($_SERVER['DOCUMENT_ROOT'] . '/path/to/s9y');
        include './index.php';
        chdir($_SERVER['DOCUMENT_ROOT']);
    }
}

Note that I don't do any output buffering; this is because the ZF dispatcher takes care of that for me. All I need to do is execute the s9y bootstrap.

So, the lesson to learn from all this: if you need to wrap an application that uses globals, find out what all of them are, and declare them in the global namespace — just setting them to null is enough — in your application bootstrap.

Clay Loveless wrote last year an article entitled Stop Writing Loner Applications in which he ranted about all the monolithic applications that act like they're the only kid on the block when it comes to user authentication. Basically, if you want to create a site that utilizes several third-party, off-the-shelf PHP apps (say, a forum, a blog, and a wiki), getting a shared authentication to work between them can be more than a little painful.

I've hit a similar problem repeatedly the past couple months: most of these apps simply are not embeddable, at least not without modifying the source.

"Why embed?" you ask. Simple: if I'm creating a site that has one or two of these applications, but also my (or my company's) own custom functionality, I may want to ensure that certain elements are present on all pages, or that I can control some of the content in all pages: a unified header and footer, ability to inject statistic tracking javascript, etc.

The predominant attitudes are either, "Don't embed our app, embed your app in ours," or "Just modify the templates." Neither of these solutions is acceptable.

Last Wednesday evening, I had the honor of presenting Zend Framework to BostonPHP, as part of an ongoing series they're holding on PHP frameworks; Horde was also represented as part of the evening's fare. It was the first time I've attended a UG, so I got the double whammy of that and being a presenter. Oh, make it a triple whammy — Boston is a 3+ hour drive from the Burlington, VT area I now call home.

All in all, the presentations went quite well. It was particularly fun to see what my friend Chuck Hagenbuch has been up to with Horde; his description and demonstration of RDO, or "Rampage Data Objects" was very cool (I really like the idea of "Horde on the Rampage" -- it's a very funny image for me), as was his working demonstration of using WebDAV to pull results via PHP in the Mac Finder.

A lot of people are interested in and working regularly with Zend Framework, at least based on the questions I was receiving. Attendees ranged from the "what does Zend do" category to the "We're standardizing on Zend Framework and use Zend products throughout our stack" category. The bulk of the comments I received were either of the flavor "I really like what I'm seeing" or wondering how mature/stable Zend_Db is. Unfortunately, at the time I was preparing the slides, there were many features in Zend_Db that can cause headaches, and I took some time to point these out; however most of these are soon to be history, due to the work of Bill Karwin and Simon Mundy, who are pushing to get a stable, usable DB abstraction layer out the door for ZF 1.0.

During the joint question and answer session, I started getting some particularly tough, pointed questions from one member of the group. I wasn't getting particularly rattled, but the moderator, Seth, decided to intervene and introduce me to my interlocutor — none other than Nate Abele of the CakePHP project. In the end, he joined Chuck and myself at the front of the room, and we had a nice panel discussing how the various frameworks handle different issues.

If you're ever in the Boston area, check to see if BostonPHP is having a meeting; it's a fun group.

My slides are now available; I've revised them slightly to fix some syntactical errors I noticed during the presentation, but otherwise they're what I presented. You may also want to check out the podcast.

A little over a year ago, I stopped using Linux as my primary desktop due to the fact that a number of programs we were using were Windows dependent. Despite getting coLinux running, I've never been completely satisfied with the setup. I missed being able to paste with my middle-mouse button, and I was constantly having character encoding issues pasting back and forth between PuTTY and windows apps, couldn't access mail easily between my coLinux and Windows partitions, and overall felt that I was losing out on some productivity by not having a native linux environment as my primary OS.

Last week, we had an infrastructure change at work, and I basically realized that my Windows + coLinux setup was going to get in the way of productivity -- and that, at this point, there were now Windows applications tying me to that OS. So, I decided it was time to go back to Linux.

This morning, I was wondering about how to extend a singleton class such that you could retrieve the new class when retrieving the singleton later. In particular, Zend_Controller_Front is a singleton, but what if I want to extend it later? A number of plugins in the Zend Framework, particularly view helpers and routing functionality, make use of the singleton; would I need to alter all of these later so I could make use of the new subclass?

For instance, try the following code:

class My_Controller_Front extends Zend_Controller_Front
{}

$front = My_Controller_Front::getInstance();

You'll get an instance of Zend_Controller_Front. But if you do the following:

class My_Controller_Front extends Zend_Controller_Front
{
    protected static $_instance;

    public static function getInstance()
    {
        if (null === self::$_instance) {
            self::$_instance = new self();
        }

        return self::$_instance;
    }
}

$front = My_Controller_Front::getInstance();

You'll now get an instance of My_Controller_Front. However, since $_instance is private in Zend_Controller_Front, calling Zend_Controller_Front::getInstance() will still return a Zend_Controller_Front instance — not good.

However, if I redefine Zend_Controller_Front::$_instance as protected, and have the following:

class My_Controller_Front extends Zend_Controller_Front
{
    public static function getInstance()
    {
        if (null === self::$_instance) {

            self::$_instance = new self();
        }

        return self::$_instance;
    }
}

$front = My_Controller_Front::getInstance();

Then the any time I call getInstance() on either My_Controller_Front or Zend_Controller_Front, I get a My_Controller_Front instance!

So, the takeaway is: if you think a singleton object could ever benefit from extension, define the static property holding the instance as protected, and then, in any extending class, override the method retrieving the instance.

One reason I've heard PHP developers use for adopting an IDE when developing is the ability to click on a class or function name and jump to the declaration. Sounds like magic, and it's definitely something I've desired.

One way I get around it is by adopting PEAR coding standards for naming my classes. Since they define a one-to-one mapping of class name to the file system (substitute the underscore character (_) with the directory separator), I can usually very quickly and easily open a class file, particularly if I start in the base directory of the project install.

Today, however, I found exuberant ctags, a library which can be used to generate an index file mapping language objects to source files and the line in the source file where they are declared. Contrary to its name, it's not just for the C language; it currently supports 33 different programming languages, including PHP.

I decided to try it out on the Zend Framework core library today. At first run, it was pretty useful. However, it was only mapping classes, and, in addition, only those defined with the single word 'class' — abstract classes and interfaces were entirely left out. So, I looked into the documentation to see if I could change the behaviour.

And, being a Unix program, of course I could. First off, you can add functions to the items it indexes with a simple flag. Additionally, you can use POSIX regular expressions to refine what it searches.

I whipped up the following script to create my tags index:

###!/bin/bash
cd /path/to/framework/library
exec ctags-exuberant -f ~/.vim/mytags/framework \
-h \".php\" -R \
--exclude=\"\.svn\" \
--totals=yes \
--tag-relative=yes \
--PHP-kinds=+cf \
--regex-PHP='/abstract class ([^ ]*)/
/c/' \
--regex-PHP='/interface ([^ ]*)/
/c/' \
--regex-PHP='/(public |static |abstract |protected |private )+function ([^ (]*)//f/'

This script creates the tag index in the file $HOME/.vim/mytags/framework. It scans for PHP files recursively through the tree, excluding any files found in a .svn directory (I'm using a checkout from the subversion repository). The file paths in the index are created relative to the tags file; this was important, because if this wasn't provided, vim was unable to jump to the file, as it couldn't find it. --PHP-kinds=+cf tells it to index classes and functions. Next, I've got three regular expressions. The first tells it to match classes beginning with 'abstract class' as classes. The second tells it to match interfaces as classes. The last is so that PHP 5 methods, which begin with a visibility operator, to be matched as functions.

Once the index file is generated (it takes less than a second), all you need to do in vim is tell it to load it: :set tags=~/.vim/mytags/framework. At this point, you can do all sorts of fun stuff. Place the cursor on a class name or method name, anywhere in it, and hit Ctrl-], and you'll jump to the file and line of its declaration; Ctrl-T then takes you back. If you change the invocation to Ctrl-W ], it will split the current window and open the declaration in the new pane. (If you're familiar with how help works with Vim, this should seem pretty familiar.)

One more reason to stick with Vim for your PHP editing needs. :-)