Installing Twig

This really couldn’t get a lot simpler with pear:

    $ pear channel-discover pear.twig-project.org
    $ pear install twig/Twig

or, you can use the Git or Subversion repos as detailed on the projects website: http://www.twig-project.org/doc/intro.html

The Application Resource

Setting up a ZF application resource for twig is a snip! The minimal config required to set up a Twig instance, is exactly that, minimal!

Simple create the class “Core_Resource_Twig” and place it in library/Core/Resource/Twig.php and consider the following code:

<?php

class Core_Resource_Twig extends Zend_Application_Resource_ResourceAbstract
{
    /**
     * @var Twig_Environment
     */
    protected $twig;

    public function init()
    {
        $options = $this->getOptions();
        $loader = new Twig_Loader_Filesystem($options['templateDir']);
        $this->twig = new Twig_Environment(
                $loader,
                $options['options']
        );
        return $this->twig;
    }
}

All we are doing here, is creating an instance of the Filesystem Twig loader, which loads templates from files, and then passing that in to the Twig Environment, along with the rest of the options from our config, which in brief, would now look something like this:

[production]
autoloaderNamespaces[] = "Twig_"
pluginPaths.Core_Resource = APPLICATION_PATH "/../library/Core/Resource"

; FRONT CONTROLLER
resources.frontController.moduleDirectory = APPLICATION_PATH "/modules"
resources.frontController.controllerDirectory.default = APPLICATION_PATH "/controllers"
resources.frontController.noViewRenderer = true

; TWIG
resources.twig.templateDir = APPLICATION_PATH "/templates"
resources.twig.options.cache = APPLICATION_PATH "/../cache/twig"

[development : production]
resources.twig.options.debug = true
resources.twig.options.auto_reload = true

That now gives us two things, a configured Twig instance, and an application resource to hold it, which will be present in the invoke args in your controller. so for the next step, we stitch it together, and make it more useable, to make things super simple, a base controller class is useful here. The reason for a base controller class rather than an action helper is simple, performance, and simplicity; no need for the complexity or auto-rendering anything, we will simply call a method at the end of each action.

Given that we are now using twig, this has two benefits, we avoid the overhead of how ZF looks up the view name to decide which view template to render, which is a part of the bottleneck of ZF, and additionally, it matches more closely to the other documentation you’ll find on Twig elsewhere, and we are doing things in a slightly different manner to how we would use Zend_View, so why try to emulate it, when we are using something very different!

<?php

abstract class Core_Controller extends Zend_Controller_Action
{
    public function twig($template, array $vars)
    {
        $twig = $this->getBootstrap()->getResource('twig');

        $template = $twig->loadTemplate($template);
        $this->getResponse()->appendBody(
            $template->render($vars),
            'default'
        );
    }
}

Rendering the template

Now that we have our base controller class, we can now use our template, in this manner from our action:

<?php

class IndexController extends Core_Controller
{
    /**
     * @var Core_Service_Posts
     */
    protected $service;

    public function init()
    {
        $this->service = new Core_Service_Posts();
    }

    public function indexAction()
    {
        $recent = $this->service->recentPosts();
        $this->twig('home.twig', array(
            'recent' => $recent,
        ));
    }

    public function viewAction()
    {
        $id = $this->getRequest()->getParam('id', false);
        if (false === $id) {
            throw new Core_InvalidIdException('No ID Present');
        }

        $paste = $this->service->byId($id);

        $this->twig('view-post.twig', array(
            'post' => $paste,
        ));
    }

}

In this example, you have the indexAction, taking the service for the posts for the application, and passing the recent posts to the template, and in the view action, taking the selected post, and passes it to the template, with the selection of template for the action being passed as the first argument to our twig method we added to the base controller class.

And now, you can find examples and documentation on how to put together your twig templates here http://www.twig-project.org/documentation.

With much excitement, I arranged to travel with Rob Allen to the conference, as we are in (relatively) close proximity, and traveling with someone is always better than traveling alone.

As the months quickly passed by, the conference schedule was soon posted, and I became immediately impressed with the lineup, with speakers from America making an appearance along with the big names in PHP from Europe, this was going to be a great conference.

As quickly as I got my voucher to book my ticket for the conference, I signed up to an extra session of tutorials, after all I was going to be there anyway. with that and the hotel and flights booked, anticipation was the state of mind for the next two and a half months leading up to the conference. Once the tutorial sessions were announced, I discovered that I was in for a treat, Solr was on the agenda, a tool which I’ve only worked with from the outside, that is being involved in a team using it, but not working with it directly myself, so finally I was to get the chance to learn something more about it, so I booked my seat in that tutorial, and resumed my previous state of anticipation.

The Drinking begins!

Finally, came travelling day. Leaving nice and early in the morning, up the M5, I stopped off and picked up Akrabat, and we headed for Birmingham airport, where what would turn out to be a long day began. Little did we know what we were in for, we were supposed to be flying at 10:50am, we eventually took off at 8:30pm! Thankfully, having a traveling buddy paid off, and the time passed quickly in the bar, and the beer began!

When we finally arrived at the hotel, many tweets later, and being kindly picked up by Michelangelo van Dam, we headed straight to the bar, to begin consumption of some fine belgian beer! (and very fine it was)

The conference begins

Kicking off with a tutorial on Solr, was Paul Borgermans, who has extensively used Solr in his work before, and gave an excellent introduction for those of us who were new to the subject, while managing to easily move on to some of the more complex subjects without causing confusion, and explaining everything with just the right amount of detail, not to little to leave you with dozens of questions, and not too much to take in at once. I came away from the session confident that I could set up and get running with Solr without much hassle, and without needing to spend a whole day in google. An excellent start!

Next up, after an excellent meal, was the Keynote. This wasn’t the first time I’ve seen Lorna or Ivo speak at a conference, and have enjoyed their talks where I have seen them before, so to have the two of them together was a real treat! Titled ’27 Ways to be a better developer’, and interspersed with humour and wit, were some really good messages, some new, some re-enforcing things that every developer should really know already, but overall a balanced talk about how to improve yourself as a developer. The Supreme Allied Commander (Matthew Weier O’Phinney) was even featured when discussing the idea of finding a mentor, and also passing that knowledge on in return.

Derick Rethans was next on my journey through the schedule, With a presentation on Geo-Location, and mapping, Mostly seemed to be aimed at using OpenStreetMap, but explained some of the nuances of how to present mapping data, and was a really interesting presentation. Perhaps less PHP involved than I expected, but had plenty of great information, and opened my mind to the possibility of not using google maps next time I need an interactive map in a website, it seems much simpler, and less restricted by google’s licensing (you can even use the data without using a map at all).

Next up for me from the schedule was, ‘Making software development tools work for you’ by John Mertic of SugarCRM, discussing pretty much exactly what it said on the tin! talking about how to choose your tools, and how to get the best from them, covering tools from issue tracking to continuous integration, source control and more.

Then ‘Designing HTTP interfaces, and RESTful web services’ by David Zülke of Bitextender. I really enjoy seeing David speak, he manages to fully inject his character and humour into his talk, and at the same time get right into technical details, and convey his point.

The Drinking Continues

At the end of the day came the closing Messages from Microsoft, and an introduction to Azure from Maarten Balliauw, and Katrien De Graeve, with Michelangelo van Dam giving us some insights into how PHP is maturing on windows. Michelangelo’s presentation promted a good deal of chatter on twitter, with his demonstration of how phing can be used to deploy the same codebase to different servers, (and deploying to linux is 2 lines and a few seconds in rsync, deploying to windows, 50,000 lines and a minute in ftp!). One feature I was sorry not to see discussed more, is Azure’s cloud simulator, which looks like a really cool tool to have, and would be nice to get running some linux vm’s in.

After this, we had a good spread of food laid on by Facebook, and the time to spend the beer vouchers given kindly by github! so over the road to the hotels second complex, where there was bowling and beer, a good mix by everyone’s standards!

Day 2

First up for me, Paul Jones, talking about benchmarking frameworks. This turned out to be totally not what I was expecting. instead of Solar Framework, trouncing the world, was a balanced and informed look at how to meter your own environment to see how different frameworks may perform for you, and how to take the steps to bring in control to ensure that you know what your framework is costing you, and what the application you build upon it costs. At the end, I think everyone came away better armed to know how to get the most from benchmarking their applications, and to take a balanced look at their systems.

Following Paul, was a talk from Scott MacVicar, talking about HipHop for PHP, which I have been following with interest for a while, and it was very interesting to see the developments since he gave a talk on this subject back in phpnw, I wasn’t sure at first if I should attend this, or another talk, but i’m glad I did, having learnt some more about what they have been doing, and learning a little more about some of the challenges that a site such as facebook faces from a technical perspective.

Then it was time for Rob’s talk on Zend Framework 2, where he announced publicly for the first time that Zend Framework 2 in Action was to be written, and that I would be working with him on it, the talk went down well with the audience, with lots of questions and curiosity from the audience, and Rob appeared to be surrounded when it was over with people asking his advice and opinion.

Next I attended an excellent talk by Keith Casey, entitled Project Triage and Recovery, which while he discussed the challenges of forking dotProject for web2Project, also went into some interesting concepts such as managing the complexity of a codebase, interacting with users, and dealing with issues which were really applicable to every project, not just getting on top of an out-of-control codebase. I came away from this brimming with ideas to take back to the office!

At the end of the day, was the closing keynote, brought to us by Elizabeth Naramore, and while it had chocolate chip cookies in the title, it was really about building a community, being the glue, and keeping it motivated. overall an excellent presentation mixed with humour, interaction from the audience and a confident speaker who left a great impression!

Closing the conference, were the raffles, and prizes, thanks for the sponsors, the speakers, and the crew, all of which brought together an excellent conference experience, and the hospitality from the crew was second to none! everybody at the conference was warm and welcoming, crew and other delegates alike, and every speaker was pleasant and approchable.

More drinking

I know it seems like a bit of a theme now, but the drinking is a very important aspect of a conference in this community. Not only do you get the chance to get drunk and have a good time, but you also make new connections, share experiences and ideas, and make friends. You could even say, that a good chunk of the magic of a conference, happens at the social, if you have not attended a conference before, try as hard as you can to make sure you can hang around for it when you attend your first one, you wont regret it!

After the close, and a quick call home, those of us who were staying at the hotel one more night, and some of the crew headed into Antwerpen for amazing pizza! and of course more beer, with the conference crew again demonstrating their hospitality driving us into the city center in their cars.

I had a fantastic time at PHPBenelux, and fully intend to be there again next year, (who knows, maybe they will accept me as a speaker!) and I’ve come back full of ideas and refreshed, and perhaps more importantly, the new faces I have met and some of the people I have met before, has also given me more leads and potential for my day to day life, so Im closing this with a huge thank you to the conference organisers, the speakers, and everyone I met for a great time!

Since the conference, new opportunities have already arisen for me, directly as a result of the social elements of the conference, what a great community we are lucky enough to have as PHP developers!

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) {
                    Zend_Registry::get('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!

And with it comes with a whole bag load of new features, 4 of which i’m very eager to get using, in Zend_Application, and Zend_Tag, and Zend_Tool, and Zend_Navigation. There is another component which interests me, which is of course Zend_Validate_Db_RecordExists and Zend_Validate_Db_NoRecordExists, which were my small contribution to this release.

Zend_Application is a whole new way to bootstrap you application, and encompasses a whole bag of new features. One of which is a new autoloader, which of course means that the old one has now been depreciated. You can find excellent instruction on upgrading your legacy applications to 1.8′s new autoloader (to avoid the notices it will generate) at Akrabats blog, His famous tutorial has also been updated to encompass 1.8 and its new features. If you want the full low-down of the new autoloader, a slightly more in depth look can be found at devzone

Zend_Tool is The new CLI tool to provide scaffolding for your applications. It will save some of the tedium of setting up an application directory strucure, creating the various bootstrap, htaccess, and other miscelanous files you need to get you application started. Even better news about Zend_Tool, it will set your new application up to use Zend_Application, so you can get started with two of the latest features, simply by starting a new project! (I can’t wait!!)

Zend_Tag is a new component for generating those lovely new-fangled tag clouds you see on everyones blogs. It is a pretty simple to use component, but possibably my favourite feature is its weighting system, which i can see being useful for more than just generating simple tag clouds, but, with a little extension, also for relevancy matching. This is something i will definatly be adding to my current CMS application project which is consuming so much of my time currently. Also worth looking at, is DASPRiD’s screencast detailing how to use Zend_Tag to generate clouds, and how the decorators work. He even demonstrates it being used in a CLI application (Genius!), and as the author of Zend_Tag, obviously watching this screencast will be like getting instruction straight from the horses mouth.

Zend_Navigation is a nice way to create menus for your site. Its also a great way to optimise your site for indexing by search engines. It also provides a way to avoid using the dreded action(viewhelper|stack) for creating menus! Put simply this component should be used by everyone. I know i will be using it as soon as i get the chance to work it into my projects.

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

This proposal has now been accepted and is available in the incubator.

During the process of refining the proposal, Ralph Schindler suggested renameing the validator, and splitting it in two, to make it as verbose as possible (i.e. the name says exactly what it does). So, an abstract class has been added, and the DbMatch name dropped. The validators are  now called Zend_Validate_Db_RecordExists and Zend_Validate_Db_NoRecordExists. check the wiki page for more information.