Our venue for the evening was Bush House, a nice place with perfectly sized meeting rooms for the 15 guys who attended.

The talk I gave, was a rehersal for my talk at PHPNW10, which is entitled ‘Zend Framework: Getting to grips‘, and is aimed at  developers who have made it past the first steps of Zend Framework, and are moving on into the realms of developing their understanding, and exploring the quirks and nuances.

My talk went down well (at-least, nobody fell asleep), besides a few mistakes on my part when putting my slides together, and gave me some valuable experience to ensure that things go smoothly at PHPNW10, and a huge thanks has to be said to everyone there once more for all the feedback, you’ve given me a much needed confidence boost!

Afterwards, it was time to head downstairs to Arnolfini‎, where we all got to mingle and socialise, and discuss all things geeky and wonderful, which is quite a refreshing experience having only experienced such pleasures when attending conferences.

It was also a pleasure to see a few guys who I have encountered over time on IRC, and also to see and appearance from Rob Allen, author of Zend Framework in Action, whom I have come to regard as a friend over the years from both IRC and bumping into at conferences over the last few years, and was kind enough to give me permission to use the pics he took for this post. Another pleasant surprise was the presence of Marcus Degalos, who will be hosting the framework shootout at PHPNW10, and is a Bristol resident, so hopefully we can expect to see much more of him at future meetings.

If you’re in the south west or wales, and you’re a php developer, come and sign up to the mailing list, and get yourself along to the next meeting. See you there! The next scheduled PHPSW meeting will be on Wednesday 13th October 2010 (Venue TBA), so we can pick apart and share our experiences of PHPNW10!

(Before anyone asks to see the slides, they will be available after PHPNW10)

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!

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