http://twitter.com/teengenerate/php

Like most Zend Framework components, the FlashMessenger needs a bit of tweaking before it’s ready to be part of your application. The main bit of tweaking we need to do involves the namespace. The messenger only has one namespace set at initialisation (default). More than often we will need a few namespaces for messaging. For instance you would often want to separate out error messages from success messages or notifications. This is where namespacing comes in. The following examples are contained in controller actions:

$this->_flashMessenger = $this->_helper
                              ->getHelper('FlashMessenger');

if ($errrors) {
    $this->_flashMessenger->setNamespace('error');
    foreach ($errors as $errorItem) {
        $this->_flashMessenger->addMessage($errorItem);
    }
} else {
    $this->_flashMessenger->setNamespace('success');
    $this->_flashMessenger->addMessage('Success.');
}
$this->_flashMessenger->resetNamespace();

Once you have this set up you can retrieve messages from specific namespaces like so:

$this->_flashMessenger->setNamespace('error');
$this->view->errors = $this->_flashMessenger->getMessages();
$this->_flashMessenger->resetNamespace();

Always remember to reset the namespace after changing it or you might get confusing messages! Changing namespaces generates a lot of repeated code so it should really be moved into an messenger object of it’s own that will handle the namespace processing for you.

I checked out most of the popular PHP framework websites, read a little about each, browsed the community and tutorial pages and after a few hours came to the conclusion that I was going to have a crack at building a site using Symfony. The main reason I chose Symfony is that it takes a completely different approach to building a website from ZF. Using Zend Framework sometimes feels like driving a tank, it’s beauty is that it’s completely flexible but the downside of this is that there’s a lot of code to write before you get to where you want. Not interesting code either. You have to write your controller skeletons, your basic models, your CRUD functions, your views. You know, the stuff you’ve written a million times. If John Rambo taught us anything, it’s that sometimes you don’t need a tank, you need a small, fast boat to get in quick and get the job done. Zend’s strength lies in long term projects that require scalability and customisation. Symfony on the other hand specialises in code generation and speeding through the boring, repetative tasks associated with getting a web application up and running.

One of the things that drew me to Symfony is the documentation. They have free books that teach you every aspect of the framework and a 24 day tutorial called Jobeet that walks you through every step of application building in Symfony. I decided to build the Jobeet app and see how it worked for me.

The first thing you notice once the environment is set up is the lack of coding needed. Symfony provides a PHP command line interface and it’s simply a case of writing some YAML configs and running various ORM scripts (Propel and Doctrine are the default ORMs). By using the command line and some simple configs you can generate the models, the database structure, the controllers, the views, the CRUD functions and associated forms. Within a few hours of work I had a fully functioning basic site and I was pretty impressed with the way Symfony handles code generation.

Symfony also comes with two front controllers instead of one. One is for the actual web application and one is for the debug version. The debug version comes with full logging and analysis tools and it’s a really nice feature. I’m sure it’ll come in useful when making small edits in live environments or doing routine maintenance and performance upgrades.

As of writing this post, I’ve only had time to run through the first 6 chapters of the Jobeet project so I’ll be writing another post when I get a bit deeper into the workings of Symfony. That’s it for now but if you’re interested in learning more, head over to the Symfony website and have a run through some of their tutorials. Even if you’re not planning on using Symfony for production sites, it’s still a useful exercise to see how a ORM-based framework like this can cut down on the amount of boring coding you have to do.

First thing we do is take the page name and replace all the spaces with hyphens, then strip out any non-alpha-numeric characters using regex. This will give you a nice URL that will make the  SEO people at your company happy. I’ve also added a suffix option here that can be used to take care of any duplicates. The logic to handle this should be kept outside this function as it’s dependent on whatever database table you happen to be using at the time.

    /**
     * generates an SEO friendly url
     *
     * @param string $name
     * @param interger $suffix
     * @return string
     */
    public static function generateUrl($name, $suffix = 0)
    {

        $alias = str_replace(' ', '-', strtolower(trim($name)));
        $alias = preg_replace('/[^A-Za-z0-9-]/', '', $alias);
        $alias .= ($suffix > 0) ? $suffix : '';

        return $alias;

    }

By using this function in any admin scripts we can now generate urls for each record by looping through the database.

Eg. If the page title you have is “This is a new article! Is it helpful?”, it will be converted to “this-is-a-new-article-is-it-helpful”. Perfect for SEO.

The example below shows how bind() events are added to individual elements. Every time a button with the class ‘myButton’ is clicked, a link is added to the container div. Because the links do not exist when the page is created, the event handlers have to be created after each element using the bind method.

$('.myButton').click(function() {
    $('#myContainer').append('<a class="myElement">Click me</a>');
    $('.myElement').bind('click', function(){
        clickFunction();
        return false;
    });
});

function clickFunction() {
    // do something here with the click
   alert('This link has just been clicked!');
}

Thankfully  jQuery 1.3 has introduced the live() and die() events. By using the live() method, it is possible to assign an event handler to a selector, even if the element doesn’t exist. If the element is created in the future, the event handler will be automatically added to it. The example below will create a click event handler on any element with the class ‘myElement’ regardless if it exists or not.

$('.myElement').live('click', function() {
    clickFunction();
});

This example doesn’t really cut down on code but it does mean you can forget about tracking the event handlers. Just assign once and forget. Bugs won’t appear in your code just because you forgot a bind() function somewhere and every subsequent ‘myElement’ element that is created will have an event handler assigned to the click event.

This has already saved me considerable time banging my head against the screen. All hail the live() event! One thing I have noticed is there is a slight performance issue when using the live event as oppose to using the bind functions so you have to weigh up the pro’s and cons of using it in javascript intensive applications.