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.

dojo.provide(\"custom.ContentPane\");

dojo.require(\"dijit.layout.ContentPane\");

dojo.declare(\"custom.ContentPane\", [dijit.layout.ContentPane], {
    postMixInProperties: function(){
        if (dijit.byId(this.id)) {
            dijit.byId(this.id).destroyRecursive();
        }
    },

    destroyRecursive: function(){
        dojo.forEach(this.getDescendants(), function(widget){
            widget.destroyRecursive();
        });
        this.inherited(arguments);
    }
});

The destroyRecursive() method is not that different from the one in dijit._Widget; the difference is that instead of calling simply destroy() on any discovered widgets, we destroy recursively.

The postMixInProperties method I added due to IE issues I've run into. Basically, even though the ContentPane was being destroyed recursively, for some reason IE was keeping a reference to the original dijit floating around. postMixInProperties() checks to see if the dijit ID is still around, and if so, destroys it recursively. This allows the ContentPane initialization to proceed.

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.

JSLint looks, at first, like it needs to be a web-based tool. However, this is not so; there are a number of JavaScript VMs you can utilize. Dojo's source builds, for instance, come with a version of Apache's Rhino, a JS VM written in Java, and JSLint provides a script for use with Rhino.

To get JSLint running on the command line using the Rhino shipped with Dojo, you'll need to download the following file:

• jslint.js

Put these files in a directory of your choosing. Then, create a file called "jslint", with the following:

#!/bin/sh
exec java \
-jar /path/to/dojo/util/shrinksafe/custom_rhino.jar \
/path/to/jslint.js $1

Note: you'll need to put in the correct paths to your Dojo installation as well as to where you placed the jslint.js file.

Make that file executable, and put it somewhere on your path. Once you do, you can invoke it quite simply:

jslint foo.js

and get some nice output. Something I will often do is to grab all JS files in a tree using globbing, and then pass them individually to the linter. In zsh, that might look like this:

% for f in *.js;do jslint $f;done

I found in most cases, following the advice of the linter eliminated any issues in IE, as well as fixed any inconsistencies I was observing in the UI. Your results may vary, of course -- but it's a tremendously useful tool to have in your toolbox if you're a JavaScript developer.

The short, executive summary:

• One trip to Israel
• One trip to The Netherlands
• One trip to California's Bay Area
• One trip to Atlanta, GA
• Three minor releases of Zend Framework
• Seven webinars, six for zend.com and one for Adobe
• Three conferences attended as a speaker, including:
  • One six-hour workshop
  • One three-hour tutorial (as a co-presenter)
  • Four regular sessions
  • Two panel sessions (one scheduled, one for an uncon)
  • Two uncon sessions (one as a co-presenter)
  • One foul-mouthed Pecha Kucha talk
• Ten Burlington, VT PHP User's Group meetings attended; I spoke at many
• One Bug Hunt week organized
• Two books reviewed as a technical editor
• Six articles for DevZone
• 50 blog entries (including this one)

Read on for the gruesome, month-by-month breakdown.

January and February

I started coding Zend_Form in earnest in January, and had a preview ready for testing mid-month. The pace continued into February, as I addressed user feedback and issues, and continued working feverishly towards what would become Zend Framework's 1.5.0 release.

I also answered many questions for and had many discussions with Cal Evans relating to his "Guide to Programming Zend Framework".

March

I gave my first webinar of the year early in March, on the subject of Zend_Form; it was very well attended, but unfortunately there was an issue recording the sound, so the recording was never released. After two more failed attempts at re-recording, we gave up. I apologize to all who have wanted to view it.

While working towards the 1.5.0 release, Ralph Schindler and I also finished up final touches on Zend_Layout and the various "placeholder" view helper implementations.

On 17 March 2008, we released Zend Framework 1.5, our first minor release following 1.0.0.

I started blogging tips and tricks for 1.5, and also writing articles for DevZone during March, and had tremendous amounts of feedback. In fact, one blog post, on "Login and Authentication", is still one of the most trafficked on my blog after 9 months.

I also began what I envisioned as a series of Vim posts, but, alas, it has resulted only in two.

April

Following the 1.5 release, I did weekly posts for a month or so covering various features of Zend Framework, including Front Controller plugins, Action Controller helpers, and View helpers. Towards the end of the month, the entire team participated in a Q&A webinar to discuss the 1.5 release.

May

At the beginning of the month, I released the last in my series of 1.5 tutorials on DevZone, covering Form decorators. This has saved me countless hours on IRC and in the mailing lists explaining how this aspect of forms work.

During this month, we also finally announced that Zend Framework would be partnering with Dojo to provide an out-of-the-box RIA solution. I began work identifying the various integration points and creating proposals for implementation. I also did a Q&A webinar with the Dojo team outlining the proposed integration.

At the end of the month, the ZF team reorganized the subversion repository to allow for an "Extras" repository, and also to ensure that projects originating in the laboratory or extras and migrating to the standard library retain all history. Even with the big notices we put on the ZF site, articles on DevZone, and posts on various blogs, we still get questions on this seven months later. Let this be a lesson to you: plan your repositories for any contingency as early as you can!

June

I started June with a trip to Israel, to visit the Zend offices. I met up with Andi in Newark, and we flew from there to Israel several rows apart in coach. One of the best meals I've ever had was after we landed and he invited me to his sister's place for dinner, and we dined on chicken marinated in home-pressed olive oil and fresh herbs, hummus, and pitas baked with fresh oregano. The rest of the week was spent in the office, in endless meetings.

Four days after returning from Israel, I flew to Amsterdam for the Dutch PHP Conference, to which I'd been invited to speak. My good friend Remi took the train up to Amsterdam to meet me the day I flew in, and we walked and walked and walked around the city, until dinnertime. Stefan Koopmanschap then met us for a lovely dinner, and I returned to the hotel to finish screenshots for the six-hour workshop on Zend Framework I was presenting the next day. The entire conference was wonderful, and I met many fantastic people, including Stefan Priebsch, Lorna Jane Mitchell, Andries Seutens, and many, many more -- plus many familiar faces, such as Sebastian Bergmann, Derek Rethans, Mike Van Dam, Felix de Vliegher, and Marco Tabini.

On my blog, I started raising the question of how we will refer to Abstract classes and Interfaces in PHP 5.3, but I think my arguments went largely unheard and/or misunderstood.

The last half of the month was spent working on both Dojo integration with Zend Framework (a task that turned out fairly easy, in large part due to some wonderful guidance from Pete Higgins), and preparing Zend_Test_PHPUnit for inclusion in Zend Framework 1.6.

July

I think I'll remember July as the month of the neverending release cycle.

August

On 8 August 2008, PHP 4 officially died. I thought about drinking a toast for about 3 seconds, forgot about it, and finished my beer.

The following Monday, we released the second release candidate of Zend Framework 1.6.0.

August, too, became part of the month of the neverending release cycle.

September

Finally, on 2 September 2008, we released 1.6.0 into the wild. My contributions included, as noted earlier, Dojo integration, PHPUnit integration, and code assistance on our Captcha solution and file upload support.

The next day, I gave yet another webinar on Zend Framework and Dojo integration, but finally actually had some code samples and working demos to show off, soundly quieting the claims of vaporware. I also started learning about Dojo release builds, under the tutelage of Pete Higgins.

Mid-month saw the fourth annual Zend/PHP Conference, this time in Santa Clara. I was involved in a marathon of seven different sessions over three days. I've rarely been so exhausted, and it's a wonder I remember anything following -- but I had a wonderful time with the PHP community following, including Jon Whitcraft, Rob Allen, the ibuildings crew, and more.

I also finally got to meet David Sklar, to whom I owe the fact of my first public speaking engagement at the first ZendCon.

Following ZendCon, there were announcements that two colleagues at Zend I respect highly were leaving for new opportunities: Mark de Visser left to join Sonatype as its CEO, and Cal Evans left to head ibuildings' new Center for PHP Expertise. I wish them both luck in their new endeavors.

October

I helped Wade Arnold complete testing of Zend_Amf as we prepared for the Zend Framework 1.7.0 release, and learned a fair deal about Flex in the process.

During this time, I also completed a technical review of Zend Framework in Action. Rob Allen and Nick Lo had contacted me earlier in the year, but I'd been unable to commit to it. In July, I agreed, only to get sucked into the neverending release cycle. Fortunately, in October I had time to complete the review. The book is very well written and organized, and I can't recommend it highly enough. I was able to give some constructive feedback and have some dialog with Rob that, hopefully, helped clarify a few areas of Zend Framework, and will hopefully help their readers.

For the 1.7 release of Zend Framework, I worked on performance benchmarking, profiling, improvements, and a best practices guide.

Late in the month, I delivered a webinar with Lee Brimelow for Adobe to showcase the upcoming AMF support in Zend Framework.

November

The last few days of October and first week of November, I organized a bug hunt week for Zend Framework, culminating in a Bug Hunt Day event held and organized by PHP Belgium and phpGG (The Netherlands). We closed out close to 150 issues over the course of the week and a couple dozen during the Bug Hunt Day, and got many contributors started on the path of professional bug squashing enlightenment.

The second week of November, I flew down to Atlanta, GA, to attend php|works.. err, php|works/pyworks. First off, a huge thank you to Elizabeth Naramore, who helped me fairly last minute to make sure I had a room to stay in. While there, I presented my Dojo and Zend Framework talk, but with some updated content. Of course, every presenter's nightmare occurred, and I had to reboot my laptop mid-stream. I surprised myself, and, I think, the attendees by actually being able to continue speaking while we waited for my machine to reboot.

I also presented a Pecha Kucha talk -- I re-branded the phrase as "Pikachu" a couple weeks earlier (a reference to the iconic character in Pokemon, a game I play with my daughter), and that phrase has, for better or for worse, stuck. My talk was on how to be banned from an open source project, and I swore entirely too much. It was a nice release, however, as I try to be politic in public usually, and sometimes just need to rant.

I got to see a ton of old and new friends alike while there -- former Zenders Mike Naberezny and Paul M. Jones, Keith Casey, Matthew Turland, Ivo and a bunch of the ibuildings crew, Pollita (sorry, I have to stop linking everyone now...), Sebastian... basically, a ton of the usual suspects. I also met a lot of new people, many of them introducing themselves as ZF users; I appreciate all of you introducing yourselves, as you are the reason I code.

The following Monday, 17 November 2008, we released Zend Framework 1.7.0, timed to coincide with the the Adobe MAX conference, as AMF support was our major story for the release. Zend_Amf has generated tremendous buzz in both the PHP and Flash/Flex communities, due to the simplicity and robustness of its design. This release also marked the first release to include the extras repository -- which now ships with community-contributed JQuery support.

December

Chris Shiflett and Sean Coates organized this year's PHP Advent Calendar, and solicited entries from a select group of PHP community members a week in advance. I didn't volunteer to contribute for the first week, but managed to get mine in on the first day... only to see it appear the very next. Hopefuly, my guide to responsible contributions will help those wondering how to report and/or fix bugs in open source projects.

I started blogging more, in part due to more free time in the evenings (it's nice when the kids go to bed at a reasonable hour!), and in part due to finally putting a number of ideas into a blogging "backlog" so that I could pick up and post when I had time. From this, I added an entry on mumbles/irssi integration, autocompletion with ZF and Dojo, created a simple pubsub implementation for PHP, and started a series of posts on how to architect models (and some concrete tips for doing so). I have more posts in December than I have in several other months combined.

Reflection

This past year, I became much more involved with both the Zend Framework and greater PHP communities, and feel I have enriched my life with many wonderful new friends -- some local, some global. I feel truly fortunate to be working in a job I love, contributing to a project that helps others do the jobs they love, and part of such an accepting and vibrant group of people.

Looking back, I travelled less, though because most of it was in a five month period, it felt like more. On that note, I vow never to do back to back trips across the big pond, as it was incredibly exhausting.

Looking ahead to 2009

I have several things to look forward to already in 2009. I'll be continuing my series of posts on models. In February, I will have an article published in a print magazine for the first tiem. I'll be speaking at PHP Quebec in March, presenting two sessions and sitting in on a panel. I hope to speak at several other conferences, and potentially write more articles and tutorials. Overall, I want to contribute more to the ecosystem of best practices in PHP, particularly in the areas of testing and deployment strategies.

I hope this post finds you in good health and spirits, and that you have a fantastic start to the new year!

The system has elements of Aspect Oriented Programming (AOP), as well as the Observer pattern. Its power, however, is in the fact that an individual object does not need to implement any specific interface in order to act as either a Subject or an Observer; the system is globally available.

Being a developer who recognizes good ideas when he sees them, of course I decided to port the idea to PHP. You can see the results on github.

Usage is incredibly simple: an object publishes an event, which triggers all subscribers.

Probably the most illustrative solution would be for optionally logging. Say for instance that you create a logger instance in your application bootstrap; you could then subscribe it to all "log" events:

$log = new Zend_Log(new Zend_Log_Writer_Stream('/tmp/application.log'));
Phly_PubSub::subscribe('log', $log, 'info');

Then, in your code, whenever you might want to log some information, simply publish to the "log" topic:

Phly_PubSub::publish('log', 'Log message...');

In production, you could simply comment out the log definition and subscription, disabling logging throughout the application. Events that publish to topics without subscribers simply return early -- meaning no ramifications for code that uses the system. You could then enable the logger at will when you need to debug or determine what events are triggering.

As another example, consider a model that has a save method. You may want to log the data sent to it, as well as the id returned. Additionally, you may want to update your search index and caches once the item has been saved to your persistence store.

Your model's save method might then look like this:

class Foo
{
    public function save(array $data)
    {
        Phly_PubSub::publish('Foo::save::start', $data, $this);

        // ...

        Phly_PubSub::publish('Foo::save::end', $id, $this);
        return $id;
    }
}

Elsewhere, you may have defined your logger, indexer, and cache. Where those are defined, you would tell them what topics you're subscribing each to.

Phly_PubSub::subscribe('Foo::save::start', $logger, 'logSaveData');
Phly_PubSub::subscribe('Foo::save::end', $logger, 'logSaveId');
Phly_PubSub::subscribe('Foo::save::end', $cache, 'updateFooItem');
Phly_PubSub::subscribe('Foo::save::end', $index, 'updateFooItem');

The beauty of the approach is the simplicity: Foo doesn't need to implement it's own pub/sub interface -- in fact, if Foo already existed in your application, you could drop in this functionality trivially. On the other side of the coin, if you have no subscribers to the events, there are no drawbacks.

Some places it could be improved:

• The ability for return values could be useful, to allow interruption of method execution or to modify arguments sent by the publisher. However, since each topic may have multiple handlers, a simple interface would be difficult to achieve.
• Exception handling. In most cases, you probably don't want method execution to halt due to a subscriber raising an exception. However, you still need some way to report such errors.

I'm excited to see what uses you may be able to put this to; drop me a line if you start using it!

Update (2008-12-30): Based on some of the comments to this post, I created Phly_PubSub_Provider, which is a non-static implementation that can be attached to individual classes -- basically providing a per-object plugin system. Usage is as follows:

class Foo
{
    protected $_plugins;

    public function __construct()
    {
        $this->_plugins = new Phly_PubSub_Provider();
    }

    public function getPluginProvider()
    {
        return $this->_plugins;
    }

    public function bar()
    {
        $this->_plugins->publish('bar');
    }
}

$foo = new Foo();

// Subscribe echo() to the 'bar' event:
$foo->getPluginProvider()->subscribe('bar', 'echo');

$foo->bar(); // echo's 'bar'

Which dijits perform autocompletion?

Your first task is selecting an appropriate form element capable of autocompletion. Dijit provides two, ComboBox and FilteringSelect. However, they have different capabilities:

• ComboBox allows you to enter arbitrary text; if it doesn't match the associated list, it is still considered valid. The text entered is submitted -- not the option value. (This differs from normal dropdown selects.)
• FilteringSelect also allows you to enter arbitrary text, but it will only be considered valid if it matches an option provided to it. The option value is submitted, just like a normal dropdown select.

Once you've chose the appropriate form element type, you then need to specify a dojo.data store. dojo.data provides a consistent API for data structures consumed by dijits and other dojo components. At it's heart, it's simply an array of arbitrary JSON structures that each contain a common identifier field containing a unique value per item. Internally, both ComboBox and FilteringSelect can utilize dojo.data stores to populate their options and/or provide matches. Dojo provides a variety of dojo.data stores for such purposes.

Defining the form element

Defining the form element is very straightforward. From your Zend_Dojo_Form instance (or your form extending that class), simply call addElement() as usual. Later in this tutorial, depending on the approach you use, you may need to add some information to the element definition, but for now, all that's needed is the most basic of element definitions:

$form->addElement('ComboBox', 'myAutoCompleteField', array(
    'label'     => 'My autocomplete field:',
));

Providing data to a dojo.data store

We're going to work backwards now, as providing data to the data store is relatively trivial when using Zend_Dojo_Data.

First, we'll create an action in our controller, and assign the model and the query parameter to the view. We'll be setting up our dojo.data store to send the query string via the GET parameter "q", so that's what we'll assign to the view.

    public function autocompleteAction()
    {
        // First, get the model somehow
        $this->view->model = $this->getModel();

        // Then get the query, defaulting to an empty string
        $this->view->query = $this->_getParam('q', '');
    }

Now, let's create the view script. First, we'll disable layouts; second, we'll pass our query to the model; third, we'll instantiate our Zend_Dojo_Data object with the results of our query; and finally, we'll echo the Zend_Dojo_Data instance.

<?php
// Disable layouts
$this->layout()->disableLayout();

// Fetch results from the model; again, merely illustrative
$results = $this->model->query($this->params);

// Now, create a Zend_Dojo_Data object.
// The first parameter is the name of the field that has a
// unique identifier. The second is the dataset. The third
// should be specified for autocompletion, and should be the
// name of the field representing the data to display in the
// dropdown. Note how it corresponds to \"name\" in the 
// AutocompleteReadStore.
$data = new Zend_Dojo_Data('id', $results, 'name');

// Send our output
echo $data;

That's really all there is to it. You can actually automate some of this using the AjaxContext action helper, making it even simpler.

Using dojox.data.QueryReadStore

We now have an endpoint for our dojo.data data store, so now we need to determine which store type to use.

dojox.data.QueryReadStore is a fantastic dojo.data store allowing you to create arbitrary queries on data. It creates the query as a JSON object:

{
    query: { name: \"A*\" },
    queryOptions: { ignoreCase: true },
    sort: [{ attribute: \"name\", descending: false }],
    start: 0,
    count: 10
}

This is problematic in two ways. First, if you were to use it directly, you'd be limited to POST requests, submitting it as a raw post. Second, and related, this means that requests could not be cached client-side.

Fortunately, there's an easy way to correct the situation: extend dojox.data.QueryReadStore and override the fetch method to rewrite the query as a simple GET query with a single parameter.

dojo.provide(\"custom.AutocompleteReadStore\");

dojo.declare(
    \"custom.AutocompleteReadStore\", // our class name
    dojox.data.QueryReadStore,      // what we're extending
    {
        fetch: function(request) {  // the fetch method
            // set the serverQuery, which sets query string parameters
            request.serverQuery = {q: request.query.name};

            // and then operate as normal:
            return this.inherited(\"fetch\", arguments);
        }
    }
);

The question now is, where to create this definition?

You have two options: you can inline the custom definition (less intuitive) and connect the data store manually to the form element, or you can create an actual javascript class file (slightly more work) and have your form element setup the data store for you.

Inlining a custom QueryReadStore class extension

Inlining is a bit tricky to accomplish, as you need to declare things in the appropriate order. When using this technique, you need to do the following:

1. require the dojox.data.QueryReadStore class
2. define a global JS variable that will be used to identify your store
3. use dojo.provide and dojo.declare to create your custom data store extension
4. define an onLoad event that instantiates the data store and attaches it to the form element

We can do all the above within the same view script in which we spit out our form:

<?php
$this->dojo()->requireModule(\"dojox.data.QueryReadStore\");

// Define a new data store class, and 
// setup our autocompleter data store
$this->dojo()->javascriptCaptureStart() ?>
dojo.provide(\"custom.AutocompleteReadStore\");
dojo.declare(
    \"custom.AutocompleteReadStore\", 
    dojox.data.QueryReadStore, 
    {
        fetch: function(request) {
            request.serverQuery = {q: request.query.name};
            return this.inherited(\"fetch\", arguments);
        }
    }
);
var autocompleter;
<?php $this->dojo()->javascriptCaptureEnd();

// Once dijits have been created and all classes defined,
// instantiate the autocompleter and attach it to the element.
$this->dojo()->onLoadCaptureStart() ?>
function() {
    autocompleter = new custom.AutocompleteReadStore({
        url: \"/test/autocomplete\",
        requestMethod: \"get\"
    });
    dijit.byId(\"myAutoCompleteField\").attr({
        store: autocompleter
    });
}
<?php $this->dojo()->onLoadCaptureEnd() ?>
<h1>Autocompletion Example</h1>
<div class=\"tundra\">
<?php echo $this->form ?>
</div>

This works well, and is an expedient way to get autocompletion working for your element. However, it breaks the DRY principle as you cannot re-use the custom class in other areas. So, let's look at a better solution

Creating a reusable custom QueryReadStore class extension

The recommendation by the Dojo developers is that you should create this class as a javascript class, with your other javascript code. The reasons for this are numerous: you can re-use the class elsewhere, and you can also include it in custom builds -- which will ensure that it is stripped of whitespace and packed, leading to smaller downloads for your end users.

The process isn't as scary as it may initially sound. Assuming that your "public/" directory has the following structure:

public/
    js/
        dojo/
            dojo.js
        dijit/
        dojox/

what we'll do here is to create a sibling to the "dojo" subdirectory, called "custom", and create our class file there:

public/
    js/
        dojo/
            dojo.js
        dijit/
        dojox/
        custom/
            AutocompleteReadStore.js

We'll use the definition as originally shown above, and simply save it as "public/js/custom/AutocompleteReadStore.js", with one addition: after the dojo.provide call, add this:

dojo.require(\"dojox.data.QueryReadStore\");

This is analagous to a require_once call in PHP, and ensures that the class has all dependencies prior to declaring itself. We'll leverage this fact later, when we hint in our ComboBox element what type of data store to use.

On the framework side of things, we're going to alter our element definition slightly to include information about the dojo.data store it will be using:

$form->addElement('ComboBox', 'myAutoCompleteField', array(
    'label'     => 'My autocomplete field:',

    // The javascript identifier for the data store:
    'storeId'   => 'autocompleter',

    // The class type for the data store:
    'storeType' => 'custom.AutocompleteReadStore',

    // Parameters to use when initializint the data store:
    'storeParams' => array(
        'url'           => '/foo/autocomplete',
        'requestMethod' => 'get',
    ),
));

If you've been following along closely, you'll notice that the "storeParams" are exactly the same as what we used to initialize the data store when inlining. The difference is that now the ComboBox view helper will create all the necessary Javascript for you.

The view script now becomes greatly simplified; we no longer need to setup any javascript, and can literally simply echo the form:

<?= $this->form ?>

Hopefully it should now be clear which method is easiest in the long run.

Next Steps

dojox.data.QueryReadStore offers much more than simply specifying the query string. As noted when introducing the component, it creates a JSON structure that also includes keys for sorting, selecting how many results to display, and offsets when pulling results. These, too, can be added to your query strings to allow finer grained selection of results -- for instance, you could ensure that no more than 3 or 5 results are returned, to allow for a more manageable list of matches, or specify a sort order that makes more sense to users.

Summary

Learning new tools can be difficult, and Dojo and Zend Framework are no exceptions. One compelling reason to learn Dojo if you're using Zend Framework, however, is that its structure and design should be familiar: it uses the same 1:1 class name:filename mapping paradigm. Additionally, because it is written to utilize strong OOP principles, familiar concepts such as extending classes can be used to customize Dojo for your site's needs.

Hopefully this tutorial will shed a little light on both the subject of autocompletion in Dojo, as well as class extensions in Dojo, and help get you started creating your own custom Dojo libraries for use with your applications.

So, to keep my hand in the game, here are a few things running through my head, or that I'm working on, or that I'll be doing soon.

Speaking at PHP Quebec

I'm speaking at PHP Quebec this coming spring, and presenting "Practical Zend Framework Jutsu with Dojo". I will be reworking the talk I did at php|works to present new features and new techniques I've been working on for effectively using Dojo and Zend Framework together. Hopefully my laptop and the projector will play nice together this time!

PHP Advent Calendar

Chris Shiflett and Sean Coates have generously donated some time and a domain to this year's PHP Advent Calendar. I was invited to submit an entry, and wrote up a piece I titled "Use Responsibly," where I discuss good development habits when consuming open source projects.

Burlington, VT PHP User's Group

This week marks the one year anniversary of regular meetings of the Burlington, VT PHP User's Group. We meet this week for a special presentation from Josh Sled of Sun Microsystems, on database indexing, joins and subqueries, database optimization, and more. If you're in the area Thursday evening, come join us!

Zend Framework 1.7.1

Yesterday, we released Zend Framework 1.7.1, the first bugfix release in the 1.7 series. Not much more to say about it, other than start downloading!

Pastebin updates

I've been continuing development on the pastebin application I developed for demonstrating Zend Framework and Dojo integration. In the past couple weeks, I've reworked it substantially, adding support for dojo.back so as to stay in the same page while utilizing the application; the results are quite good. One side effect of this is that I've reworked and simplified the view scripts, and added REST, JSON-RPC, and XML-RPC endpoints to simplify the XHR infrastructure. I'm getting pretty happy with the results...

...which has led me to jump to the next milestone, which is to integrate the bug application I worked up for the Dutch PHP Conference last summer and start creating a suite of collaborative developer tools. These are intended to do three things: (1) demonstrate best practices and good architecture when using Zend Framework, (2) demonstrate appropriate techniques when using Dojo with Zend Framework, and (3) to scratch an itch (I'd like to use these tools for my personal projects). I've code named the project "Spindle", a name I like for its rich connotations. If you're interested in contributing, drop me a line, and I'll set you up with commit access. Or fork it, and send me patches. Whatever.

Oh, and one more thing...

Ha! fooled you!

Seriously, though, there are, to quote something I saw on twitter today, a "metric shit-ton" of holidays and observances of just about every faith and geographic origin in the coming month. Enjoy, and best tidings of the season to you!

I'm constantly trying to improve the application. I've done one webinar and one UnCon session showcasing it, and will be presenting it at Dojo Develper Day in Boston this Monday as well as at php|works later this fall, and want to keep the materials up-to-date and freely available. To this end, I've created a Github repository so you can track the latest developments, as well as pull custom tarballs:

• Pastebin on Github

All patches and feedback are welcome!

ZendCon was alternately exhausting, rewarding, educational, fruitful, infurating, and ultimately wonderful. I've been to every single ZendCon so far -- I started at Zend a scant month before the inaugural event -- and have spoken at each. My first time speaking was a fluke; David Sklar had just started at Ning and had to back out of his "Configuring PHP" tutorial session. Mike Naberezny and I were drafted to take it over, and we had N+1 attendees, where N was the number of speakers. Since that inauspicious beginning, I've gradually taken on more sessions and stuck around to participate in the conference more. I can honestly say that this was the biggest, busiest, and most community focussed ZendCon I can remember.

This year, I was involved in a marathon seven -- yes, that's right, seven -- sessions over three days, and only finally got the last day off. Mike and I did our Best Practices tutorial session on Monday, which was very well attended. Based on the numbers of people raising their hands as we asked if they were implementing or familiar with the various practices we enumerated, we may be able to begin doing more advanced, in-depth sessions in the future.

On Tuesday, Stefan Priebsch roped me into convinced me to help with a "round table" UnConference session on the role of ORMs in PHP. The consensus we had was that ORM tools are quite good for prototyping and rapid development, but that any good ORM solution should de-couple the data access layer to allow stubbing with well-tuned SQL when performance becomes a consideration.

Later that morning, I did a presentation on Getting Started with Zend Framework. I developed this presentation to follow our newly re-launched Quick Start. The talk was very well attended, and I received some excellent questions from attendees following the talk. I hope to streamline it in the future so it can be presented as a screencast or webinar. If you are interested in the material, I suggest heading to the link above and downloading the quick start materials; they are well-documented and will cover at least as much as I covered in the talk.

In the afternoon, I did another unconference session, this time performing my Rich UIs and Easy XHR with Dojo and Zend Framework talk. (Did I mention that conference attendees could not seem to get enough Zend Framework material?) I really enjoyed doing this talk live this time (I've done it previously for a webinar) -- I received some wonderful questions, but even better, I was able to gauge the audience reactions to what I was presenting. I was pleased to see people getting as excited about Dojo as I've become, and I hope to see that enthusiasm grow. Dojo is truly a fantastic choice when it comes to javascript toolkits, and I think I suitably demonstrated how easy it is to use Dojo now from Zend Framework.

Tuesday afternoon, I presented my session on Zend_Form. We'd originally planned to do a talk on Zend_Layout and Zend_Form, but there's at least two hours of material there that simply does not condense to 1 hour. Instead, we had Ralph present a session on Zend_Layout during an UnConference session, while I focussed on Zend_Form. Again, it was fun to do this in front of a live audience -- albeit one I could barely see from my perch on the mainstage. I saw some places to trim for next time -- which will allow me to show off Zend_Dojo integration with Zend_Form in the future.

Immediately following that, I headed off to do yet another UnConference session with Lorna Jane. Keith Casey had approached me on Monday following the tutorial Mike and I presented, indicating that there were requests for an "svn tips and tricks" presentation for the UnCon. I told him to ask Lorna Jane if she'd be interested, as I'd seen her do an excellent presentation on the subject at the Dutch PHP Conference in June. After some back and forth, we decided to do it together, and sketched out a rough outline early Wednesday morning. The talk was very well attended, and again had great audience participation. Doing the presentation has inspired us to consider submitting a joint proposal for a conference in the future.

I quickly ran downstairs, only to find I was immediately wanted for a "Meet the Team" session. This has become a staple at ZendCon, and has had led to some... interesting... interchanges in the past. This year, the session was packed, and we had some very good discussions touching on every Zend product -- from Zend Framework to Zend Platform. There were certainly some hecklers, but all of it was in good fun, and we had a brilliant time. (Man, I think hanging with the UK folk has worn off on my vocabulary.)

I actually attended fewer sessions than I was involved in, which was unusual and strange. Every one I was able to attend was quite good. Standouts for me include Jay Pipes' tutorial on Join Foo, which raised many questions for me and sparked a number of discussion points all week. Additionally, I was delighted to be able to attend Alex Russell's Dojo talk; I've exchanged dozens of emails with him over the past months while doing the ZF/Dojo integration, and it was fascinating to hear his summary of the state of HTML and browser support, as well as how he feels Dojo fits in the ecosystem. I was fortunate enough to be able to grab him afterwards so we could have lunch and talk shop -- and got an even larger surprise to discover he was not only familiar with all aspects of the Dojo support I'd done, but had used much of it!

Being as busy as I was, I didn't have much chance to stop and enjoy the community until Wednesday evening. And the community is quite vibrant! I have often been behind in my slide preparations or tied up in meetings and unable to "join the fun" that often marks good PHP events. This time, I felt quite tapped into the community, as well as welcomed by all. I had innumerable conversations, both with people wholly unfamiliar to me, people I've seen yearly at ZendCon, and people I've been "seeing" virtually on IRC and the mailing lists. The strength of any open source project is only as good as the community it attracts, and on this basis alone, PHP is thriving.

So, goodbye, ZendCon08 and all my new and old friends -- let's hope we can meet again next year!

First off, you may now view my Dojo Webinar online (requires login and registration at zend.com). Attendance was phenomenal, and I've had some really good feedback. If you want to see it live, I'm giving the talk (with revisions!) at the ZendCon UnConference, at Dojo Developer Day Boston later this month, and at php|works in November. I hope to be able to show new functionality at each presentation.

Second, I've completed what I'm calling version 1.0.0 of the pastebin application I demo'd in the webinar. The PHP code is fully unit tested (though I haven't yet delved into using DOH! to test the JS), and incorporates a number of best practices and tips that Pete Higgins from Dojo was kind enough to provide to me. When using a custom build (and I provide a profile for building one), it simply flies.

• Download the pastebin application

The pastebin application showcases a number of features besides Dojo: Zend_Test_PHPUnit was used to test the application, and Zend_Wildfire's FireBug logger and DB profiler are used to provide profiling and debug information.

Finally, ZendCon is next week! I'll be around, but already have a packed schedule (1 tutorial, 2 regular sessions, an UnCon session, a meet-the-developers session... and that's just what I know about!). I look forward to meeting ZF users and developers, though, so feel free to grab me and introduce yourself.

This particular item had to do with how I was consuming custom Dojo build layers within my code. I contacted him afterwards to find out what he suggested, and did a little playing of my own, and discovered some more Dojo and javascript beauty in the process.

The code in question looked like this:

Zend_Dojo::enableView($view);
$view->dojo()->setDjConfigOption('usePlainJson', true)
             // ->setDjConfigOption('isDebug', true)
             ->addStylesheetModule('dijit.themes.tundra')
             ->addStylesheet('/js/dojox/grid/_grid/tundraGrid.css')
             ->setLocalPath('/js/dojo/dojo.js')
             ->addLayer('/js/paste/main.js')
             // ->addLayer('/js/paste/paste.js')
             ->registerModulePath('../paste', 'paste')
             ->addJavascript('paste.main.init();')
             ->disable();

The lines he was commenting onwere the addLayer() lines.

As noted in my webinar, layers, or custom builds, are a fantastic feature of Dojo. Dojo is incredibly modular, and acts in many ways like a good server-side library should -- only include what is needed, and when its needed. The problem comes at deployment: the user suddenly experiences a situation where the application is making dozens of requests back to the server to get what it needs. The solution is to create a custom build, which pulls in all dependencies into a single file, inters any templates, and then does minification heuristics on the code prior to stripping all whitespace and compressing it. Once done, you now have a single, small file that needs to load on the request -- making the final deployed application snappy.

When I displayed this during the webinar, I noted that after doing so, you have to change your code to point at the new build -- and that's what the two lines I pointed out are for. In essence, one is for development, the other for production. Of course, this is just ripe for problems -- you forget to switch comments in production, or accidently re-merge the development version, etc.

Pete showed me another solution that was much more elegant, and which also got rid of another line in that solution above, the addJavascript()

The solution is to write your code in the same layer file as you'll compile to. When doing so, you can put all your dojo.require() statements in the file, as well as mixin any code you want in the main module namespace:

dojo.provide(\"paste.layer\");

/* Dojo modules to require... */
dojo.require(\"dijit.layout.ContentPane\");
/* ... */

/* onLoad actions to perform... */
dojo.addOnLoad(function() {
    paste.upgrade(); 
});

/* mixin functionality to the \"paste\" namespace: */
dojo.mixin(paste, {
    /* paste.newPasteButton() */
    newPasteButton:  function() {
        var form = dijit.byId(\"pasteform\");
        if (form.isValid()) {
            form.submit(); 
        }
    },
    
    /* ... */
});

In my original code, I had a "paste.main.init" method that performed all my dojo.require and dojo.addOnLoad statements, but these now can be simply a part of the layer -- eliminating more work for me.

Then, when creating the profile, you simply have it create the layer in the same file -- in this case, paste/layer.js -- but also have it create a dependency on the original layer file. The compiler will ensure that the original code gets slurped into the build. As an example:

dependencies = {
    layers: [
        {
            name: \"../paste/layer.js\",
            dependencies: [
                \"paste.layer\",
                /* other dependencies...*/
            ]
        },
    ],
    prefixes: [
        [ \"paste\", \"../paste\" ],
        /* other prefixes -- dijit, etc. */
    ]
}

This changes the original ZF snippet above to simply:

Zend_Dojo::enableView($view);
$view->dojo()->setDjConfigOption('usePlainJson', true)
             // ->setDjConfigOption('isDebug', true)
             ->addStylesheetModule('dijit.themes.tundra')
             ->addStylesheet('/js/dojox/grid/_grid/tundraGrid.css')
             ->setLocalPath('/js/dojo/dojo.js')
             ->addLayer('/js/paste/layer.js')
             ->registerModulePath('../paste', 'paste')
             ->disable();

Not much shorter -- but because I no longer need to worry about changing the file name, I can rest easier at night.

I'll be blogging more tips such as these in the coming weeks, to help support the new Dojo integration in Zend Framework.