Valid HTML is important for a great many reasons, the most important of which is ensuring consistency across all of your visitors browsers. The first step to making sure that your site appears correctly on all the browsers is to ensure that your HTML is valid. Even if the goons at Microsoft continue to ignore the standards and do their own thing, if you at least ensure your html passes validation, then fixing things for Internet Explo(r|it)er of all its versions is a far easier task, and usually possible with a few simple extra styling rules in your CSS.

What is a front controller plugin

A front controller plugin is like an observer for the front controller. It provides several events which can be hooked at the various stages of the dispatch cycle. These events are

• routeStartup: Called before routing takes place
• routeShutdown: Called after routing has occured, but before the dispatcher is invoked
• dispatchLoopStartup: Called before the dispatchloop begins, essentially the same as routeShutdown
• preDispatch: Called before an action is dispatched (also before preDispatch of your controller, and after its init)
• postDispatch: Called after an action is dispatched
• dispatchLoopShutdown: Called when the dispatching is complete

A simple example of a Front Controller plugin is to automatically change the layout based upon the active module.

For this, you may do something as follows:

class Lupi_Controller_Plugin_ModuleLayout extends Zend_Controller_Plugin_Abstract
{
    public function routeShutdown(Zend_Controller_Request_Abstract $request) {
        // Changes the Layout based on the module name
        $modulename = $request->getModuleName();
        $layout = Zend_Layout::getMvcInstance();
        $layout->setLayoutPath("../application/modules/{$modulename}/layouts")
                     ->setLayout($modulename);
    }
}

What is Tidy

Tidy is a binding for the Tidy HTML clean and repair utility which allows you to not only clean and otherwise manipulate HTML documents, but also traverse the document tree.[source:http://uk.php.net/manual/en/intro.tidy.php]

The Tidy extension for PHP provides numerous functions for assisting a developer with coding performant, valid, and accessible HTML.

It does this through a variety of methods, but generally it works in 3 steps. configure, parse and repair.

class Lupi_Filter_Tidy implements Zend_Filter_Interface
{
    /**
     * @var tidy
     */
    protected $_tidy;

    /**
     * @var tidy
     */
    protected $_encoding = 'UTF-8';

    /**
     * @var array
     */
    protected $_config = array('indent' => true,
                                         'output-xhtml' => true,
                                         'wrap' => false,
                                         'show-body-only' => true);

    /**
     * Filter the content with Tidy.
     *
     * @return string
     */
    public function filter($content)
    {
        $tidy = $this->getTidy($content);
        $tidy->cleanRepair();
        return (string) $tidy;
    }

    /**
     * Gets the Tidy object
     */
    public function getTidy($string)
    {
        if (!is_string($string)) {
            throw new InvalidArguementException('Expected string, got: ' . get_type($string));
        }

        if (null === $this->_tidy) {
            $this->_tidy = new tidy();
        }

        $this->_tidy->parseString($string, $this->_config, $this->_encoding);
        return $this->_tidy;
    }
}

The above example is a simple filter, which will correct and escape a HTML fragment, suitable for use in a Zend_Form where you wish to accept user input. (NOTE: Though Tidy does a damn  good job of cleaning up input, what it does not do is guarantee that the output will be XSS safe).

HTML Tidy has a huge number of options available, one of my favourites being “bare” which removes MS-Word specific attributes and styling which will ruin your output. (No, no matter how many times you tell your clients not to paste straight from word into your editor, they will still do it!). I won’t even try to explain all the options here, so instead, find a full list of the options available for tidy on its sourceforge site.

Using Tidy with a Front Controller Plugin

Ok, So you can use tidy for filtering user input, what about using it to effectivly clean my documents and ensure my output is always valid?

In the previous example, I set the “show-body-only” option, which will force the tidy component to only output the body of the document. This is needed because tidy would have added a doctype, html, head and body tags around the user input. this does set to an automatic option, and should only return the complete document if it detected a body tag, but why risk the user sticking a body tag in there?

For the next example, we have a Front controller plugin, which allows us to filter the output html of our application, so that we know we always have valid output.

<?php

class Lupi_Controller_Plugin_TidyOutput extends Zend_Controller_Plugin_Abstract
{
    /**
     * @var tidy|null
     */
     protected $_tidy;

    /**
     * @var array
     */
    protected static $_tidyConfig = array('indent'            => true,
                                          'indent-attributes' => true,
                                          'output-xhtml'      => true,
                                          'drop-proprietary-attributes' => true,
                                          'wrap'              => 120,
                                          );
    /**
     * @var string
     */
    protected static $_tidyEncoding = 'UTF8';

    public static function setConfig(array $config)
    {
        self::$_tidyConfig = $config;
    }

    public static function setEncoding($encoding)
    {
         if (!is_string($encoding)) {
             throw new InvalidArgumentException('Encoding must be a string');
         }
         self::$_tidyEncoding = $encoding;
    }

    protected function getTidy($string = null)
    {
        if (null === $this->_tidy) {
            if (null === $string) {
                $this->_tidy = new tidy();
            } else {
                $this->_tidy = tidy_parse_string($string,
                                                 self::$_tidyConfig,
                                                 self::$_tidyEncoding);
            }
        }
        return $this->_tidy;
    }

    public function dispatchLoopShutdown()
    {
        $response = $this->getResponse();
        $tidy     = $this->getTidy($response->getBody());
        $tidy->cleanRepair();
        $response->setBody((string) $tidy);
    }
}

When you are using this, it is a good idea where possible to use full page static caching, so your not fixing the same errors over and over again!

Instant feedback with Firebug + Firephp for assisting development

Ok, so now we have valid HTML, thanks to a filter. How does this help with actual development? well in short, it doesn’t, as we have no feedback about what its actually fixed. So onto the next step, getting some nice reporting, in a real handy manner. For this, we will use FirePHP, so that all the information we need is sent to the console on every request. This information can even include automated accessibility testing (really handy for government funded work, which usually has requirements on meeting accessibility standards).

So, firstly you need to set up your FirePHP Logger, this is a simple task, simply add the following method to your applications bootstrap:

protected function _initWildFire()
{
    //Don't use in production!
    if (APPLICATION_ENV != 'development') {
       return;
    }
    $this->bootstrap('db');
    $db = Zend_Db_Table::getDefaultAdapter();
    $profiler = new Zend_Db_Profiler_Firebug('All DB Queries');
    $profiler->setEnabled(true);
    $db->setProfiler($profiler);
    $writer = new Zend_Log_Writer_Firebug();
    $logger = new Zend_Log($writer);
    Zend_Registry::set('logger', $logger);
}

This simply sets up a logger, and also does something else useful, it adds a Profiler to the default database adapter, which will log all your queries for you. A little out of the scope of this post, but useful, so I left it in there for you.

The last 3 lines are really the important bit, they set up the write and log component which we will be using to send messages to FirePHP, so we can see validation errors and warnings in our FireBug console! Setting the logger in the registry here is also handy, so we can actually get our logger from anywhere without any hassle. you may also return it from the init method, and use the invoke args to get it.

Now for the really useful bit, the plugin itself.

class Lupi_Controller_Plugin_TidyOutput extends Zend_Controller_Plugin_Abstract
{
    /**
     * @var tidy|null
     */
    protected $_tidy;

    /**
     * @var array
     */
    protected static $_tidyConfig = array('indent'            =>true,
                                          'indent-attributes' => true,
                                          'output-xhtml'      => true,
                                          'drop-proprietary-attributes' => true,
                                          'wrap'              => 120,
    );

    protected static $_diagnose = true;

    /**
     * @var string
     */
    protected static $_tidyEncoding = 'UTF8';

    /**
     * Switch diagnosing HTML mode
     */
    public static function setDiagnose($diagnose = true)
    {
        self::$_diagnose = (bool) $diagnose;
    }

    public static function setConfig(array $config)
    {
        self::$_tidyConfig = $config;
    }

    public static function setEncoding($encoding)
    {
        if (!is_string($encoding)) {
            throw new InvalidArgumentException('Encoding must be a string');
        }
        self::$_tidyEncoding = $encoding;
    }

    protected function getTidy($string = null)
    {
        if (null === $this->_tidy) {
            if (null === $string) {
                $this->_tidy = new tidy();
            } else {
                $this->_tidy = tidy_parse_string($string,
                                                 self::$_tidyConfig,
                                                 self::$_tidyEncoding);
            }
        }
        return $this->_tidy;
    }

    public function dispatchLoopShutdown()
    {
        $response = $this->getResponse();
        $tidy     = $this->getTidy($response->getBody());

        if ('development' === APPLICATION_ENV) {
            if (true === self::$_diagnose ) {
                $tidy->diagnose();
                $lines = array_reverse(explode("\n", $tidy->errorBuffer));
                array_shift($lines);
                foreach ($lines as $line) {
                    Lupi_Logger::log($line, Zend_Log::INFO);
                }
            }
        }
        $tidy->cleanRepair();
        $response->setBody((string) $tidy);
    }
}

So, hows it work? Well its essentially the same as the previous plugin, except I have added a section to the dispatchLoopShutdown method, and added a static method to enable / disable the logging output (sometimes it can get in the way!).

The reason for splitting the diagnosis output by line and sending it over multiple log calls, is because the Firebug console will not respect the newline characters, and instead tried to display it all on one line, making it hard to read. splitting it over multiple entries makes things much tidier. reversing the array also makes things a little easier to read!

In closing, heres some examples of the output for you:

An example of the Tidy output for valid xhtml

An example of the Tidy output with some errors in it

The other day, a wonderful thing arrived in the post, fresh from Björn Schotte of mayflower.

The poster covers many of the commonly used components, and their parameters. I have had it on the wall for about 2 weeks now, and it has become something of a crutch already, and makes it very handy to quickly check, for example whether it’s dispatchLoopShutdown or dispatchLoopShutDown in a FC plugin, or what the parameters for the headLink helper are (two things I always have to double check!)

Mayflower is a partner of Zend, and offers many training and consulting services for PHP companies, as well as developing their own software solutions, such as the “Chorizo!” security auditing suite, and consulting for the popular lightweight webserver “lighttpd”.

Check out the mayflower site at http://www.mayflower.de/en, and drop Björn Schotte an email if you are interested in a poster of your own, he may have some left!

Creating a nice, easy to maintain form, starts with a form class. Creating your forms procedurally in your controller/actions is horrid. please don’t do it.

To start with creating your form classes, you need your own namespace in your library. If you don’t have this, register one. This can be done by adding an _initAutoloading method to your Bootstrap. below is a short example. its not comprehensive (you can also do this in your ini i believe, but I use php configuration files similar to DASPRiD‘s, and i’m not trying to show how to set up autoloading here.)

class Bootstrap extends Zend_Application_Bootstrap
{
    //...
    /**
    * Initilise autoloader and library namespaces
    */
    public function _initAutoloading()
    {
        $loader = Zend_Loader_Autoloader::getInstance();
        $loader->registerNamespace('My_');
    }
    //...
}

Your next task, create a form. This is pretty simple. I will demonstrate using just a few fields. Create a file in your library called My/Form.php

class My_Form extends Zend_Form
{
    /**
    * Set up form fields, filtering and validation
    */
    public function init()
    {
        $this->setMethod(Zend_Form::METHOD_POST);
        //Username
        $this->addElement($uname = new Zend_Form_Element_Text('username'));
        $uname->setLabel('Username')
              ->addValidator('Db_NoRecordExists', false, array('table' => 'users',
                                                               'field' => 'username'))
              ->addValidator('Alnum', false, array('allowWhiteSpace' => true));
        //Email
        $this->addElement($email = new Zend_Form_Element_Text('email'));
        $email->setLabel('Email')
              ->addValidator('Db_NoRecordExists', false, array('table' => 'users',
                                                               'field' => 'email'))
              ->addValidator('EmailAddress', false);
        //First name
        $this->addElement($firstname = new Zend_Form_Element_Text('firstname'));
        $firstname->setLabel('First name');
        //Last name
        $this->addElement($lastname = new Zend_Form_Element_Text('lastname'));
        $lastname->setLabel('Last name');
    }
}

Now that your basic form is created, you need to add a method to perform your CRUD. I’m not actually going to cover the D (delete) as thats realy simple, and doesn’t require the form, which is the focus of this post.

This method should take an array for the post data, and a Zend_Db_Table_Row to provide the save functionality. In this example the DB columns have the same names as the form fields, this means we can set values with less code. As we are using Zend_Db, there should be no injection problems with this method, as everything is automagically quoted.

    //...
    public function process (array $post, Zend_Db_Table_Row  $row)
    {
        $this->setDefaults($row->toArray());
        // If the id (primary key) is null then this is a new row, else it is an existing record
        if (null !== $row->id) {
            // Record already exists, exclude it from db record validation.
            $this->getElement('username')
            ->addValidator('Db_NoRecordExists',
                                 false,
                                 array('table'    => 'users',
                                          'field'     => 'username',
                                          'exclude' => array ('field' => 'id',
                                                                      'value' => $row->id)));
            $this->getElement('email')
            ->addValidator('Db_NoRecordExists',
                                 false,
                                 array('table'    => 'users',
                                         'field'     => 'email',
                                         'exclude' => array ('field' => 'id',
                                                                    'value' => $row->id)));
        }
        if (sizeof($post) && $this->isValid($post)) {
            try {
                $row->setFromArray($this->getValues());
                $row->save();
                return true;
            } catch (Exception $e) {
                $this->addDescription('There was an error saving your details');
                return $this;
            }
        }
        return $this;
    }

The Controller / Action

Now that we have created our nice form (which is capable of CR and U)  now we need to use it from within out controller and model to perform the update or insert and interact with the user.

For this, you need 3 actions in your controller, Create, update, and delete (the delete I will not cover for the before mentioned reasons).

class UserController extends Zend_Controller_Action
{
 
    public function newAction ()
    {
        $this->_helper->ViewRenderer->setScriptAction('userform');
        $users = My_Users();
        $user = $users->getNewUserForm($this->getRequest()->getPost());
        if (true === $user) {
            $this->_helper->flashMessenger()->addMessage('New User Created');
            $this->_helper->redirector->gotoUrlAndExit(/** confirmation url here **/);
        }
        $this->view->form = $user;
    }
 
    public function editAction()
    {
        $this->_helper->ViewRenderer->setScriptAction('userform');
        if (false === ($id = $this->_getParam('id', false))) {
            throw new Exception ('Tampered URI');
        }
        $users = My_Users();
        $user = $users->getEditUserForm($this->getRequest()->getPost());
        if (true === $user) {
            $this->_helper->flashMessenger()->addMessage('Details Saved');
            $this->_helper->redirector->gotoUrlAndExit('user/edit/' . $id);
        }
        $this->view->form = $user;
    }
}

To explain what all this is about, Both actions do pretty similar things (infact this can be consolidated into a single action, but for clarity and ease of replication, I am using two).

There are two things which are pretty important in this, one is the use of the redirector, and the other is the checking of the ID before it is used. In my opinion when an id is passed in a url which is invalid, then a 404 should be raised. So in my error controllers i look for a variety of exception types so that i can debug, but only output a 404 for these in production.

Now looking more closely at the action code, we have calls to getxxxxUserForm() on our models. The return value of this is what we wish to inspect, as you could see in the process method we created earlier, we return boolean true, only when the record saves correctly.  So we do a strict check for this boolean value, and if it is true, we know that we can safely redirect our user. The redirect is an important step, it stops the browser trying to post the data again if the user clicks refresh after their record is created / updated. And the final note is that the flashMessenger is used to pass a message to inform that user that their action was completed on.

Also worth noting is that i have set both actions to use the same action name in the viewRenderer. This allows you to consolidate this common script into one. (repeat after me, Dont Repeat Yourself!). The view script for this is pretty simple.

<div class="messages">
<?php foreach(Zend_Controller_Action_HelperBroker::getStaticHelper('flashMessenger')
             ->getMessages() as $message) : ?>
<p><?php echo $this->escape($message);?></p>
<?php endforeach;
</div>
<?php echo $this->form;?>

The Model

In the model, we now need two simple methods to tie the lot together. Now some people might (read: Will) argue that the model should be performing validation, I would argue that with this method, the Model *is* performing the validation, you are simply making use of a library class to perform this function, much in the same way you use Zend_Db_Row. Feel free to flame about this below, but I’m sticking with this, and it provides clean easy seperation, and provides a good clean mechanism to provide user feedback.

class My_Users
{
    /**
    * @var Zend_Db_Table_Abstract
    */
    protected $_table;
    //....
 
    /**
    * Retrieves a new user record, and processes a form against it.
    *
    * @param array $post
    * @return boolean|Zend_Form Boolean true if a save successfully occurs, a populated form on all other conditions
    */
    public function getNewUserForm(array $post)
    {
        $form = new My_Form();
        return $form->process($post, $this->_table->createRow());
    }
 
    /**
    * Retrieves a user record, and processes a form against it.
    *
    * @param array $post
    * @return boolean|Zend_Form Boolean true if a save successfully occurs, a populated form on all other conditions
    */
    public function getEditUserForm(array $post, $id)
    {
        $row = $this->_table->fetchRow($table->select()->where('id = ?', $id));
        $form = new My_Form();
        return $form->process($post, $row);
    }
}

Well, this really doesn’t need much explanation. this simply provides glue between the parts above. You can make these a little more complex, and infact you probably should (I do!) by sanitizing your input from the controller in the form of the user id, $id, in the edit method.

In conclusion

This post has partly been inspired by comments in #zftalk and in part, by the search for a good way to deal with forms, and I look forward to any feedback. Before there is any cirisitm of the validation and filtering in the form, I have kept is minimal to illustrate how the form element deals with two validators of the same name (by overwriting the first instance) and how that can be leveraged to your advantage, and also to keep the code minimal to outline the actual process, and not how to add validators. for that go and RTFM!

This part of the Framework causes the dispatch to loop. This is a costly process, as it involves quite alot. It also adds some further issues to your application design, such as where you should put code. for example if you have some code in your predispatch, and your looping through two actions in that controller, that code will be run twice. This is obviously, not good, and quite un-needed. Further complications can be added when it comes time to add ACL or authentication.

There is an even worse part of this feature, the Action View Helper. This helper basically creates an additional dispatch, copying the request object, and creating a loop-within-a-loop . The setting up of the dispatch process is a costly one, anyone who has profiled their code will have seen just how much of the process of a Zend Framework application this eats up. Creating a whole extra dispatch must be a bad idea, even the Zend Framework Performance Guide notes this fact

So, lets go through some reasons for this being bad.

Why its bad

Performance

Every time you go through the dispatch process, there are a number of things which are done, which will be completly un-nessicary for your action, namely calling preDispatch and postDispatch for each action which is called. This often results in questions in #zftalk of “Why is my ACL being called twice?”. If you have an ACL being built in your preDispatch (as many people quite rightly do) this means if you have 3 calls to different actions, your ACL will be built, and queried 3 times, and if you haven’t cached your ACL object, this may incur extra overhead from calls to database queries.

This is even more apparent if you use the action helper, as the request is copied, and a new dispatch created (profile your code and see just how much overhead this involves, its a lot!).

Unnecessary Complexity

Trying to follow the application flow through an application which utilises the action stack adds a level of complexity which need not be there.

If you want to see what’s going on at a URL, you should be able to go to that action, and see which model methods are being invoked, and what is being passed to the view.

Design Issues

This is the biggest reason for not using the action stack. If you are using the action stack, you are almost certainly a long way from a true “MVC” design. The units of code you are using in your actions, probably belongs in the model.

Your model should encapsulate all the code to extract data, insert data, and manipulate objects, so all your controller action should include is a bunch of calls to the model to fetch data, or insert/update it, but in the form of single method calls only. remember you should be directing the data to the model, not manipulating it.

Why it is good

Illusion of DRY coding

The action stack can lead you into a false sense of security that your writing nice “DRY” code. You are in fact writing dry code, but usually in the wrong place, in fact, if your code is not abstracted into your model, it will end up no-longer being dry, as you will end up with two actions with overlapping functionality, and as such, overlapping code!

The way forward

Fat Models, Thin Controllers

Your controllers should be minimalist. they exist only to direct data, and to provide some interface to HTTP actions such as redirects.

The bulk of the code in your application should be in your model. For example, if you are writing a blog application, and the action you are writing produces a list of posts. This should require in the action, nothing more than a call to $model->getPosts(); possibly passing one or more paramaters from the URL (such as year and month) as parameters to the method.

This not only allows you to do away with the action stack, but also allows your code to be portable throughout the application, in true DRY style.

There is an upcomming book, which has a very good overview of how these kinds of models should be written. You can read it here

View Helpers

View helpers can be useful for items which you frequently need, or for items which are simply too small to justify writing a whole view script for them. there is a good example in the performance guide.

When you want to perform some logic before rendering a view script, a view helper can also be useful to help keep your layout or view free of large switches or if statements. For example this can be something like rendering a login form when a user is not logged in (which would require no view script, only a Zend_Form object), and a menu when they are, or be useful to set up some context for a view partial before rendering it, so that your controller does not have to pass a variable to the view when it would be some default value.

(Partial) Views

Partial views do the leg work of replacing the actionstack. In your partial views, you should call read-only methods of the model, to build items such as menus. this could be something like $model->getSideBarMenuItems(); which would return a dataset to loop through and render.

Some other notes

There has been an issue raised in the Zend Framework JIRA (ZF-5840) with regard to removing the action view helper for ZF version 2.0. This is somewhere you may wish to post your opinion on this subject (keep it specific!), or vote to have it removed .

Unfortunately I was unable to find a ‘simple’ method of doing this already documented, so I experimented a little, and threw away some very in-elegant ideas, and finally came up with the following technique, after discovering the Zend_Dojo_Data.

Firstly, I added a method to my tree model to walk the tree, and build an array suitable for turning into the required structure for the json.

<?php
 
class SiteTree extends Zend_Db_Table_Abstract
{
 
//....
 
private function _walkTree(Array $root = null, $path = null)
{
    if ($root === null) {
       $root = $this->getBranchChildren(0);
    }
    $arrNodes = array();
    $i = 0;
    foreach($root as $branch) {
        $thisPath = ($path === null) ? '/'.$branch['branch_name'] . '/' : $path . $branch['branch_name'] . '/';
        $key = ($branch['parent'] == '0') ? $branch['id'] : $i;
        $arrNodes[$key]['id']       = $branch['id'];
        $arrNodes[$key]['label']    = $branch['branch_name'];
        $arrNodes[$key]['path']     = $thisPath;
        $arrNodes[$key]['iconClass']     = 'folder';
        $arrNodes[$key]['children'] = array();
        if ($branches = $this->getBranchChildren($branch['id'])) {
            $arrNodes[$key]['children'] = $this->_walkTree($branches, $thisPath);
        }
    $i++;
    }
    return $arrNodes;
}
 
//....
 
}

This function recursively maps the database into a nested array. Please note, this function will cause many database queries on deep tree structures, so I really would advise you cache the return of this function, so to keep queries to a minimum.

The line “$key = ($branch['parent'] == ’0′) ? $branch['id'] : $i;” is important. For Zend_Dojo_Data to output the correctly formatted json, you need to have an associative array for the top level (root) nodes, and indexed arrays for all of their children.

Next, this data needs to be turned into json for the tree. To do this, I simply created a new action to use as the source for the json, and inserted the following:

public function jsonNewpageAction()
{
    Zend_Dojo::enableView($this->view);
    Zend_Layout::getMvcInstance()->disableLayout();
    $tree = new SiteTree();
    $treeObj = new Zend_Dojo_Data('id', $tree->getTree());
    $treeObj->setLabel('label');
    $treeObj->setMetadata(array('path' => '/'));
    $this->view->tree = $treeObj->toJson();
}

Setting the Label is important here, it is used to determine which attribute of each node is its label, next the Metadata attribute “path” I used for my customisation of the tree for my own needs, which you will see later. The view script for this action simply echo’s the tree value.

The next step is to create the view to output your tree. this part is where the real fun begins, as you can get carried away with tweaking the dojo widget if your not careful.

The following lines were added to the action with my form on it. (The tree is not part of the form, I simple made mine interact with a read only element inside it)

Zend_Dojo::enableView($this->view);
 
$this->view->dojo()->requireModule('dojo.data.ItemFileReadStore');
$this->view->dojo()->requireModule('dijit.Tree');
$this->view->dojo()->requireModule('dojo.parser');

This will add the require statements to the view, so that the required dojo parts are available.

And in the view itself, you need at least the following:

<div dojoType="dojo.data.ItemFileReadStore"  url="/admin/pages/json-newpage" jsid="jsonData"></div>
<div dojoType="dijit.tree.ForestStoreModel" jsId="treeModel" store="jsonData" rootId="treeRoot" rootLabel="Home" childrenAttrs="children" ></div>
 
<div dojoType="dijit.Tree" model="treeModel" labelAttrs="label" ></div>

The first div, is the part which will read your json from the first action I listed. If you have only a single root node, you may get away without the second div, which is the ForestStoreModel. The ForestStoreModel had me scratching my head for a while, as I had no idea I needed it, and I kept finding errors in my FireBug console. Eventually I found this page on the dojo site.

If you were to put all this together now, you would probably end up with a working tree. BUT, it can be improved. In my tree, all the leaves would actually represent folders, but as default they look like little documents, not good at all. So I asked around in IRC, and was told I needed to google getIconClass, which put me on to writing this,

<div dojoType="dijit.Tree" model="treeModel" labelAttrs="label" iconClass="dijitFolderOpened">
 
<script type="dojo/method" event="getIconClass">
    return  'dijitFolderClosed';
</script>
 
</div>

As you can see, a script is inserted INSIDE the container of the tree, and the event attribute tells the script which even it is responsible for overriding.

If you run this now, you will find that all of the folders in the tree are now closed. Not good, as the nice opening and closing folders as you expand/contract elements are lost. This can be changed by adding another attribute to the script:

<script type="dojo/method" event="getIconClass" args="item, opened">
    return (opened ? 'dijitFolderOpened' : 'dijitFolderClosed');
</script>

The args attribute allows arguments from the item firing the event to be passed to the script. so a simple ternary, and you can switch between opened and closed folders.

Update

You may also find this post at codeutopia.net useful if you are working with tree’s in Dojo / Zend Framework