(Then again, I should know better than to work off of someone’s code when they term themselves a “Web Craftsman” and have personal philosophies as headlining elements of their “about me” page.) See also: New Media Douchebags Explained.)

If you’re banging your head against this like I have been for the past four hours, you’ve probably figured out a few things. First, the library files that are required to make the javascript work need to be called in a particular order. That order is:

1. The MooTools 1.2 –FULL– compressed library. Yes, I know he says you only need a few components. Yes, he lied. Selecting the components he specified will give you an error along the lines of “window.scroll is not a function at Swiff.Uploader.js (line 62)” … so save yourself the time and just pull down the full compressed/mangled MooTools.
2. Fx.ProgressBar.js
3. Swiff.Uploader.js
4. FancyUpload2.js
5. script.js

Stray from that order, and you develop problems. Also, I found that instead of using

window.addEvent('load',function ...

as the first line of script.js, it was better to use

window.addEvent('domready',function ...

.

Second, let’s take a look at the sample file that’s supposed to magically save what we spit out. Specifically, script.php — which receives the ajax update based on a session variable that’s set, and then saves the information with an indexed .ini file. First off, it’s hard to debug. Let’s use PHP’s output buffering functions to help that. You can use this snippet of code to write a log of what’s going on:

 13  $logfile = fopen($folder.'logfile','a');
 14  ob_start();
 15  var_dump($_FILES);
 16  var_dump($_POST);
 17  var_dump($_GET);
 18  fwrite($logfile,ob_get_contents());
 19  ob_end_clean();

What you’ll notice is that, with the default code that comes with the script, you’ll have the same session ID and since the session ID is created in the javascript and each session ID is incremented in the PHP script, you’ll overwrite your file if you’re uploading multiple files — which was the whole purpose of using flash and AJAX in the first place! This is what we call a brillant(sic) programming decision… or really, one where the developer just didn’t really THINK before he wrote it. I’ve rewritten my function to simply create a directory in the ‘uploads’ folder with a batch name that I enter on the main form. After all files have uploaded successfully (or not), I have a ‘continue’ button that does a bunch of database work and sucks the text of the files into the database.

Now, I’m working with a Zend Framework application here — this means that I need to make a few changes. First, the script depends on not having any authentication ahead of the request. While the browser will still maintain the session, the ajax requests won’t have the browser’s cookies and therefore will bounce off of any preDispatch authentication. To get around this but still stay secure, I generate a (hidden) temporary session ID, store it in the database, and clear the table on a regular basis.

I’m on a crunched deadline and still don’t quite have things working yet, but in the next day or two I’ll post the fruits of my labor. Too bad this uses MooTools and not Dojo… as far as I know, Dojo still doesn’t have a flash-compatible uploader that will allow multiple selection.

But back to where I started: Harald, dude, you ain’t no web “craftsman” if someone needs to spend 8 hours learning your code and writing workarounds before they can implement it.

The documentation for Zend_Test_PHPUnit requires that you break out your configuration into a plugin as shown in Matthew’s sample pastebin application.

One of the strengths of the Zend Framework is that there’s no one way to do anything. Sure, there’s ways that are set up by default and you can discover these defaults by reading the manuals, but you can get outside of those defaults pretty quickly and easily. For me, one of the hardest things to do is to imagine just how to use the powerful plugin system and excellent collection of extensible that Zend Framework comes with. Matt used both to great effect in this application and I want to learn how and why he made the design decisions he did in order to make my own work better.

I’m going to take a look at how Matthew did his implementation of the basic structure and some of the details and journal what I learned in the process of dissecting this sample application.

Front Controller and Bootstrapping

Let’s get right down into the nuts and bolts. The good news is that the way Matt does things makes your index controller nice and compact and usable in any context without having to monkey around a lot with configuring the path to your base directory as you move between different development, staging/testing, and production servers. It also enables you to use PHPUnit for unit testing without having to go through any contortions to get the right base libraries in place.

<?php
defined('APPLICATION_PATH')-
    or define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/../application'));
$paths     = array(
    '.',-
    APPLICATION_PATH . '/models',
    realpath(APPLICATION_PATH . '/../library'),
);
ini_set('include_path', implode(PATH_SEPARATOR, $paths));
require_once 'Zend/Loader.php';
Zend_Loader::registerAutoload();
 
include dirname(__FILE__) . '/../application/bootstrap.php';
 
Zend_Controller_Front::getInstance()->dispatch();

The next component you’re going to have to work on is the bootstrap PHP. There’s a couple things to point out. First, it re-implements the dirctory application path search. That’s because the bootstrap (and not the front controller) gets called to load all the libraries when we’re using PHPUnit for unit testing.

<?php
defined('APPLICATION_PATH')-
    or define('APPLICATION_PATH', realpath(dirname(__FILE__)));
defined('APPLICATION_ENV') or define('APPLICATION_ENV', 'development');
 
if (defined('BOOTSTRAP')) {
    require_once 'Zend/Loader.php';
    Zend_Loader::registerAutoload();
}
 
$front = Zend_Controller_Front::getInstance();
$front->registerPlugin(new My_Plugin_Initialize(APPLICATION_ENV))
      ->addControllerDirectory(APPLICATION_PATH . '/controllers');

The last two lines are what we care about from the bootstrap. Remember that Zend_Controller_Front implements the Singleton pattern. Unlike the index.php file, which calls dispatch(); against Zend_Controller_Front, the bootstrap adds a plugin and a default controller directory. The plugin’s where the fascinating stuff happens for the front controller.

The Controller Plugin

To set the basic defaults that most sample apps I’ve seen have all lumped into the front controller or bootstrap, Matthew’s pastebin application extends a Zend_Controller_Plugin_Abstract into a plugin aptly named ‘Initialize’.

class My_Plugin_Initialize extends Zend_Controller_Plugin_Abstract

The constructor’s pretty simple. It sets the environment variables including the application path (note that the environment variables assume production settings if another is not already set. Production settings should be the most tightly locked down with no errors or logging shown publicly), makes sure that the Zend Framework loads if it hasn’t already, and it grabs the Zend_Controller_Front instance and registers the Initialize plugin.

The Initialize Plugin

Plugins, in general, are a collection of functions that can be triggered automatically during the lifetime of an object. You can find out more about Zend_Controller plugins in the framework manual. The important thing about extending Zend_Controller_Plugin_Abstract is the functions that you overload — routeStartup, routeShutdown, dispatchLoopStartup, preDispatch, postDispatch, and dispatchLoopShutdown. If you don’t recognize the significance of these places within the controller’s dispatch loop, stop here and go review the Zend_Controller basics.

Matthew’s Initialize plugin doesn’t instantiate all of the database and other objects until he starts up the router. The routeStartup function is overridden as below:

public function routeStartup(Zend_Controller_Request_Abstract $request)
    {   
        $this->initControllers()
             ->initLog()
             ->initCache()
             ->initDb()
             ->initView();
    }

Each function is pretty clear on what it does, and you can add steps to each while keeping the freedom, segregation, and modularity intact — something that was definitely lacking in the way I was building my front controllers. The initControllers() function is a great example — in this case, it only has one line in it. In a larger, more complex application with an administration section, you could add the controller directories for modules in other folders.

Next time I have the chance to sit down and write, I’ll take a dive into the dojo stuff. Till then, you can download Matthew’s pastebin app at his site.

My client’s specification called for two behaviors that monkey with ZF’s usual domain.tld/module/controller/action or domain.tld/controller/action routing mechanism. They wanted to use a subdomain to load the client’s customer-customized skin (i.e. customer1.domain.tld, customer2.domain.tld) — no problem. The issue arose when they also wanted to have domain.tld/customer1 and domain.tld/customer2 work the same as the subdomain. Obviously, customer1 and customer2 are not going to resolve to valid controllers, which results in an exception being thrown and the error page being displayed unless a valid static route is found…

Jeff made a huge contribution by looking at the problem at a much lower level. I was considering using the routing mechanism to accomplish this by adding a whole bunch of static routes ahead of the default router. But with an install that’s supposed to support hundreds of my clients’ customers, it’s not exactly practical to load that list for every single request! Instead, the customer name being passed in as a controller is indeed an exception, and should be handled as such!

To make this work, the first thing that needs to change is that Zend_Controller_Front needs to throw exceptions instead of passing them to the error controller. You can do this by using

$front = Zend_Controller_Front::getInstance();
$front->throwExceptions(true);

The following feels to me like a code stink, but for all intents and purposes is a valid coding practice when handling exceptions. We’re basically going to tell the front controller to “run the front controller once with the default routing rules, and if it breaks, run again with a custom routing rule.”

try {
  $front->run(BASE.'app/controllers');
} catch  (Zend_Controller_Dispatcher_Exception $e) {
  $myRoute = new Zend_Controller_Router_Route(
      '/:customer/:action/*',
      array(
         'controller' => 'index'
         ,'action' => 'index'));
}
  $router->addRoute('default',$myRoute);
  $front->setRouter($router);
  $front->throwExceptions(false);
  $front->run(BASE.'app/controllers');
}

I don’t think you actually need that $front->setRouter() call in there, but it’s not hurting anything … Do note the call to restore the default behavior of Zend_Front_Controller::throwExceptions() back to false. That’s important or your error module won’t have exceptions routed to it correctly.

Thanks, Jeff! Owe you a beer for that one.

In response: At least part of the problem is that we STILL haven’t defined the question. Is it that we develop a web application to solve problems in the most efficient and graceful way? Or is it that we develop a web application in the most maintainable and understandable way?

To extend Jack’s metaphor of hammers and nails, the former would involve using a different hammer every time we need to drive a hammer into different wood. But you could quickly build up an environment where you had many different nails driven into boards at different depths and angles due to the blows of so many hammers. If you’ve driven the nail too deep for the wood, you may not be able to get it out at some point in the future without destroying the wood completely — aka one of those oft-talked-about failed development projects.

The discussion of how to develop web applications and what technology to use isn’t just a computer science decision, it’s a business decision. As someone who approaches computer problems from a utility and maintainability perspective, I want three things from a development tool. First, I want it to set (but not force) a style so that all programmers can code in a similar fashion, and programmers who are new to the project can walk in and get a feel for things within a few minutes. Second, I want it to be maintained and maintainable into the future as the language and development methods change. Third, I want it to be based on a stable technology that scales well. These are all utility things, considered at a much more abstract level than the computer science problems that Jack talks about.

If programmers didn’t search for new tools, the web would still look like it did in 1995, and we’d all still be developing CGI applications in C. Be thankful that the world moves on and that there are people and companies willing to develop and pursue new ways of doing things. The dogmatic approach some developers take towards their favorite technology isn’t bad, per say. It’s just part of the darwinian selection of the platforms and technologies that will move on. And in some cases, the programmers who won’t, ground beneath the ceaseless ever-rolling wheels of progress.

It’s fine to allow people to search for new tools and to be evangelists of their favorite tools and processes. On their own time. When they come to work at a job (be it consulting or other), someone needs to be laying down guidelines of how to do a project, and someone needs to enforce that all projects within one cone of perception use the same technologies, or use technologies that will be compatible in the future.

Standardization is the only way to maintain a high level of support. Corporate development jobs regularly fail because someone had to do it their way. (I’m guilty of this too, but I’ve learned my lesson.) It’s the responsibility of the lead programmers to make sure that this doesn’t happen. Even if Zend Framework or Symfony or Ruby on Rails or some other technology is the most elegant and fastest way to solve a problem, don’t do it unless that’s what your group has standardized on, supports, and knows. If you’re a PHP shop, don’t write a webapp in Python. If you’re a MySQL shop, don’t use Postgres for this one project to “try it out.” Don’t. Just don’t. Pick one thing that’s good at many areas and just use it.

That isn’t to say that you shouldn’t improve your chosen one. Doctrine exists because some developers wanted an ActiveRecord implementation in PHP that was as easy to use as Rails’ is. So they wrote one. Symfony came from nearly the same place. Zend Framework’s rapidly arriving ajax integration is a direct outgrowth of what Symfony did with theirs. Just keep in mind that it’s not features from the programmer’s point of view that matter, it’s features from the point of view of the downstream developers that will support the application in the future and the systems administrators who have to maintain the platform that you’re on. If you keep it simple and just pick one for your particular shop, they can keep it simple too. And simple means stable. Stable, maintainable, and understandable means happy users, and are considered features by your users.

Make sure you deliver those features, or your project too will fail.