Actually, it is possible to truncate your data even with foreign key constraints. It can be dangerous if you’re not careful about what you delete, but the following code can be useful in Doctrine 2.x if you have a need for emptying tables programmatically:

The raw query before and after the truncate statement tells MySQL to forget about foreign key constraints, so it just blindly empties your table(s). Hopefully this will save people some time.

Listing Files in glob vs opendir

Its worth mentioning that glob and opendir/readdir are very different entry-points for file management. The former is solely used to list files that match a given pattern string. For example, glob('/tmp/*.php') will return an array containing all files in the system’s /tmp directory that have a .php extension. With opendir/readdir however, a file resource handle is returned which allows further file manipulation. This can be powerful in its own right, but if its simple file listing that you want then opendir/readdir isn’t the right tool for the job and here’s a good reason why.

Performance

The performance gain from using glob and opendir/readdir are quite vast. The benchmark we used created a mixture of 2000 PHP, text and CSV files inside a directory already containing hundreds of other files (it used the system’s /tmp directory where a lot of logging and system dump files are placed). We then used each approach in turn, recording the time before and after the process and also purging the files in the directory between each run so that the operating system’s disk cache’s were cold between runs.

The results are shown below, with the numbers representing an average over 10 individual tests. We used Ubuntu Server 64-bit as our platform of choice, although running it on other distros and operating systems proved to result in the same outcome. We were not able to benchmark performance on Windows as we didn’t have an install available, although it would interesting to see how their cmdlet implementation performs compared to a true glob.

Time based performance:

Using glob: 0.006263 seconds
Using opendir/readdir: 0.30983 seconds

Memory based performance:

Using glob: 1.227562 MB
Using opendir/readdir: 1.149849 MB

Whilst memory usage is a fraction more, the gain in processing time is nearly 5 times quicker. In terms of request time, that’s quite a big difference. If you’re using opendir/readdir to list files in your web application, you are doing it wrong.

Documenting

If you asked 1000 programmers for their thoughts on writing documentation, I bet you’d struggle to find 5 who say they enjoy it. Documentation is always an after thought, and something that many popular open source projects massively overlook (just take a look at ZF2′s documentation on caching). I believe that good documentation starts from the very first line of code. If we’re creating a new class, then we should be making starting with a class doc comment that is well rounded and thoroughly explains to the viewer what this class and its instances represent in the application. Whilst this seems like basic common sense to most developers, the number of classes that I come across with zero documentation which have been written by talented developers is bemusing.

Consider the following extrapolated example from Tickit…

<?php
//...
class Configuration implements ConfigurationInterface
{
    //...
}
?>

Above is what I seem to come across 9 times out of 10 when I open up a file. What does this class actually do? Configuration is semantically vague at this point, does it represent a set of configuration values? Does it process configuration values or does it hand them off to another class? We could always trawl through the implementation details of the class but this leaves puts a lot of work back on the maintainer, and so much information is lost between implementation and maintenance. The best person to document the class is the creator.

<?php
//...
/**
 * Reads and processes configuration information for the cache bundle
 *
 * @author James Halsall <james.t.halsall@googlemail.com>
 */
class Configuration implements ConfigurationInterface
{
    //...
}
?>

This example now gives us a little bit more information about what the class does and, whilst not perfect it gives the maintainer a quick overview of the class and whether or not this is what they’re looking for.

We could say that method documentation is even more important in some ways. Let’s suppose we have a method that carries out the following process after a member logs out…

• Clears the $_SESSION
• Removes client cookies
• Deletes the user’s row from user_session table in the database

If we document properly then should something not be working quite right at least the maintainer has a point of reference for what this method should be doing. In contrast, if we hadn’t bothered to write a doc block for the method then our maintainer would have to start stepping through code to find out why the user hadn’t been logged out properly. Whilst debugging is part of a developer’s repertoire, why should we make the lives of a maintainer more difficult than necessary?

Exceptions

PHP has a decent standard library of exceptions, ranging from the base Exception class to the BadMethodCallException and RuntimeException. Yet even though we have these “ready made” exception classes providing semantic value, many developers seem to think the base Exception class is the only one to throw when something goes wrong.

An example demonstrates the difference in readability between using correct the base Exception class as opposed to more semantically valid exceptions.

<?php
    try {
        $params = array(/* some values */);
        $db = $this->db->connect($params);
    } catch (Exception $e) {
        // something went wrong, not sure without seeing the exception message
    }

From this snippet, it is difficult to immediately see what could possibly go wrong inside the connect method. We know that we’ll catch the Exception, but how do we display a decent error message to the client if we don’t have some more semantic information about what went wrong? Was it a problem connecting to the database? Or did we pass an array when we should have passed a string as the argument?

Here’s the same piece of code, but with better exceptions being used…

<?php
    try {
        $params = array(/* some values */);
        $db = $this->db->connect($params);
    } catch (InvalidArgumentException $e) {
        //oops, passed in an invalid parameter
    } catch (RuntimeException $e) {
        //oops, a bad configuration value somewhere
    } catch (DatabaseConnectionException $e) {
       // can't connect to the database
    }

In this second snippet we can immediately see that we expect three things to (potentially) go wrong. The first is an InvalidArgumentException, which indicates that some value passed into the connect method is illegal. The second is the RuntimeException, which means we can’t realistically recover from it and in this case indicates that some database setting in the application configuration is wrong. The final exception is a custom DatabaseConnectionException class, which might be thrown when the database is unreachable.

Error Messages

Readability applies with error messages as well as the chosen exception classes. If we attempt to write to a file cache and something goes wrong, our error message should be providing enough information to directly pinpoint the problem. There are always cases where something may happen that we haven’t accounted for, but these will usually be due to a change in behaviour of a third party library or an upgrade in PHP. They are few and far between in most dynamic applications, so we should endeavour to write informative error messages.

Consider an example I came across recently…

<?php
    //...
    try {
        $cache = new FileCache();
        $cache->write(/* some variables */);
    } catch (Exception $e) {
        die('Cache not writable');
    }

Whilst this is quite an abstract example, there is so much wrong with this exception handling that it would be better off if it hadn’t been caught at all. Exceptions should only be caught and handled under two situations…

1. We can programmatically recover from the thrown exception, or..
2. We can provide a better exception message to the developer / user

Neither of these are true in this example (which I came across on a fairly large scale website recently), which is what makes it so terrible. A better way to handle this would have been…

<?php
    //...
    try {
        $cache = new FileCache();
        $cache->write(/* some variables */);
    } catch (Exception $e) {
        die(sprintf('The file cache cannot write to %s', $cache->getCacheDir()));
    }

Obviously the better approach would be to not even catch the exception at all (providing that the FileCache is throwing an exception with a helpful message itself).

Wrap Up

Writing better code doesn’t just mean solving a problem in the least amount of lines, or using triple nested ternary statements as though no other programmer would ever have to read the code ever again (this is also something I’ve seen recently). Just by documenting, picking proper exception classes, writing better error messages and always thinking about readability we can immediately create a more maintainable application or website without having even touched unit testing or mess detection (which we should all be doing by now). These things might take that bit more of our time, but without being selfish we enable maintainers to be more productive much quicker.

Turns out that it was pretty straight forward, and it seems to have resolved my issues. These are the steps I took to update my installation of PECL Imagick, but they should work if you have the Imagick core library on your system and are just in need of the PHP extension for it.

cd ~/
wget http://pecl.php.net/get/imagick-3.1.0RC1.tgz
cd imagick-3.1.0RC1
./configure --prefix=/usr/lib --with-bzlib=yes --with-fontconfig=yes --with-freetype=yes --with-gslib=yes --with-gvc=yes --with-jpeg=yes --with-jp2=yes --with-png=yes --with-tiff=yes
sudo make
sudo make install
vim /etc/php5/conf.d/imagick.ini (add the line "extension=imagick.so")
sudo /etc/init.d/apache2 reload

To verify your installation, you should have the “imagick.so” extension file in /usr/lib/php5/20090626.

Utilising Symfony2′s Event Model

Symfony2 has a great plethora of internal events that you can ‘hook’ into. In our case, we want to hook into a kernel event called which will fire whenever a request is made by the client browser. In your User bundle, create a services.yml file (e.g. src/App/UserBundle/Resources/config/services.yml) as follows:

services:
  activity_listener:
    class: App\UserBundle\Listener\Activity
    arguments: [@security.context, @doctrine]
    tags:
      - { name: kernel.event_listener, event: kernel.controller, method: onCoreController }

This is quite straightforward, this is just telling our application that when the kernel.controller event is fired we want our kernel to also call the onCoreController() method in our App\UserBundle\Listener\Activity class (we’ll create that in a minute). Before we move on to creating our event handler class we need to register our services.yml file with our main kernel. We can do this by editing app/config/config.yml and adding an import directive at the top of the file…

imports:
    - { resource: @AppUserBundle/Resources/config/services.yml }

The Event Handler Class

Now we have to create our event handler class, which will do most of the work. I decided to call my class Activity, but you can call it whatever you like as long as you make sure to amend your services.yml file to contain the same name. Our file will reside at src/UserBundle/Listener/Activity.php…

namespace App\UserBundle\Listener;
use Symfony\Component\Security\Core\SecurityContext;
use Symfony\Bundle\DoctrineBundle\Registry as Doctrine;
use Symfony\Component\HttpKernel\Event\FilterControllerEvent;
use DateTime;
use App\UserBundle\Entity\User;
class Activity
{
    protected $context;
    protected $em;
    public function __construct(SecurityContext $context, Doctrine $doctrine)
    {
        $this->context = $context;
        $this->em = $doctrine->getEntityManager();
    }
    /**
     * On each request we want to update the user's last activity datetime
     *
     * @param \Symfony\Component\HttpKernel\Event\FilterControllerEvent $event
     * @return void
     */
    public function onCoreController(FilterControllerEvent $event)
    {
        $user = $this->context->getToken()->getUser();
        if($user instanceof User)
        {
            //here we can update the user as necessary
            $user->setLastActivity(new DateTime());
            $this->em->persist($user);
            $this->em->flush($user);
        }
    }
}

Be sure to update your User class with the correct properties (e.g. last_activity) in order for the setters to work and you’re away.

One of these issues only occurred when using two LIKE conditions in the WHERE clause. Another issue was caused when having multiple SUM methods in the SELECT, aliasing them and then using the alias name in the WHERE clause. The result was a broken query, a very basic syntax error you think Doctrine engineers would have tackled from early on.

I’m not naive though, it’s probably too much to expect to have PDO working nicely with SQL Server, especially seeing as the defacto driver is still marked as experimental in the PHP API.

If you’re unlucky lucky enough to get the chance to work with SQL Server and Doctrine, then you’ll be aware of the issues that plague the library, it’s something I expect Doctrine to have resolved in version 2 of their ORM.

FreeTDS

Not all of the blame lies at the door of Doctrine, sure it has it’s parse engine errors, but there are times when the driver is clearly not working as it should.

PDO_DBLIB uses Sybase and FreeTDS to connect and communicate with SQL Server. The configuration is quite simple, and although you have to compile from source on older platforms it is usually available through a package manager such as apt-get or yum. The biggest headache came last week, when queries executed directly via PDO (bypassing Doctrine’s DQL) where hanging unexpectedly. No server output, no exceptions… nothing. Checking logs didn’t help either, it seemed as though PHP’s call stack fell into a bottomless pit as soon as PDO executed a query. Articles online didn’t help, suggesting that moving to use the ODBC driver is a better solution (I personally disagree, and think that the ODBC driver can be even more flaky).

Solving Hanging Queries

The FreeTDS config file is made up of several host blocks, which allow you to hand off the connection configuration to the FreeTDS library and allow PHP to simply connect to a host name. A host block looks something like as follows…

[sqlserver2]
host = 192.168.1.14
port = 1433
tds version = 5.0


The magic configuration option I was missing in the host block was initial block size. In the official documentation it is referred to as “the initial protocol block size”, which basically means how big a block of data the established socket will transmit. For some reason, the default setting of 512 was causing the hanging queries (in fact, when checking the FreeTDS debug log, it was terminating the connection internally but not relaying it back to PHP – hence the hang). However, by increasing this block size in increments of 512 and re-testing the faulting queries I was able to find an optimum setting of 1536, which resolved the issue.

All in all? Try to avoid Doctrine and SQL Server where you can. Although Doctrine 2 should provide better support (in theory), it will still be reliant on the PDO_DBLIB or PDO_ODBC drivers… both of which have their fair share of problems.

Assuming you already have a grid panel (Ext.grid.GridPanel or Ext.grid.EditorGridPanel) setup, we need to add in an event listener to help with our context menu creation. Ext.grid.GridPanel has several listeners available to help with this, these are

• rowbodycontextmenu
• rowcontextmenu

Both of these events are fired when the user right-clicks on a row in the grid, but the first of them requires the optional config enableRowBody being set to true in the grid’s GridView. We will use the latter, as we’re assuming that we’re not in need of any special grid row manipulation (hooking into both of these events would prove a better option if you’re using the enableRowBody config). Our Ext.grid.GridPanel code may now look something like this…

var grid = new Ext.grid.GridPanel({
   border: false,
   title: 'Sample Grid',
   loadMask: true,
   viewConfig: {
       forceFit: true,
       autoFill: true
   },
   ds: new Ext.data.JsonStore({ ... }),
   cm: new Ext.grid.ColumnModel({ ... }),
   sm: new Ext.grid.RowSelectionModel({ singleSelect: true }),
   listeners: {
       'rowcontextmenu' : function(grid, index, event) {
            //do something
       }
   }
});

You may notice that we’ve added three arguments to our rowcontextmenu event handler function. These are

• grid – The Ext.grid.GridPanel that we’re tying into
• index – The row index that we right-clicked on
• event – The right-click event object, containing useful information about what we right clicked

The next step is to create a function that will generate our context menu when we perform the right click, obviously this will be called from within our rowcontextmenu event handler. In our menu we will add items that will alert some information from our grid’s store. This will look something like below…

function showMenu(grid, index, event) {
      event.stopEvent();
      var record = grid.getStore().getAt(index);
      var menu = new Ext.menu.Menu({
            items: [{
                text: 'Show Job ID',
                handler: function() {
                    alert(record.get('job_id'));
                }
            }, {
                text: 'Show Customer',
                handler: function() {
                    alert(rec.get('customer_name'));
                }
            }]
        }).showAt(event.xy);
}

Firstly, we create an Ext.menu.Menu object that will contain our menu items, and then we add our items in line by using the items config. The last part of this function uses the showAt method on our menu object. This tells ExtJS to show the menu at a specific set of X and Y coordinates as specified in our click event. The last thing for us to do is tie our function into the event handler we specified on our grid earlier…

listeners: {
    'rowcontextmenu' : function(grid, index, event) {
         showMenu(grid, index, event);
    }
}

Now when we right click on our grid’s data, we should see something similar to this…

A sample ExtJS right-click context menu

Whilst this is a simple example of context menus, it provides a very quick insight into how easy it is to achieve desktop-like experiences using ExtJS. If you have any questions, don’t hesitate to get in touch.

A few weeks back, when I got my brand new MacBook Pro I decided to play around with ZendServer, and ended up changing things so much that I decided to just do a clean install. So I followed Zend’s method of uninstalling the server and proceeded to install my new, fresh copy. I was a little surprised when I was receiving errors from my mysql instance…

ERROR 2002: Can’t connect to local MySQL server through socket ‘/tmp/mysql.sock’ (2)

I did a little digging around my Mac, I tried running a find..

sudo find / -name mysql.sock

But this returned nothing. The mysql.sock file is apparently located at /usr/local/zend/mysql/tmp/mysql.sock or alternatively /tmp/mysql.sock, but mine had vanished from the file system completely. After a little digging, I found a shell script bundled in with ZendServer, /usr/local/zend/bin/uninstall.sh. Running this script cleaned out my current installation and after performing another clean install of ZendServer I had my mysql.sock file back where it should have been.

It’s pretty strange as to why Zend haven’t updated their instructions for removing ZendServer correctly, and it can potentially cause a lot of issues if you’re hoping to use mysql in the future.

Just a quick note on the following post, I am assuming that the user already has basic knowledge of the Ext Calendar Pro component, and that they have a simple example already working.

Recently on a work project I was required to create a Calendar based interface for controlling which staff are on-call for specific days. I was a little confused at how you could go about adding custom fields and rendering calendar events differently using Ext Calendar Pro, so I did a bit of digging through the source code and thought I would share my findings here and save someone else some time.

The Calendar component uses store mappings to let the developer map custom fields in the calendar’s eventstore to server-side fields (sent from the HttpProxy). For each custom field in an event record in the calendar you must specify the custom mapping. To specify our mappings we must modify the Ext.ensible.cal.EventMappings object directly before we create our Calendar. For example, if we wanted to store a custom field on each event which would record the employee’s name, we would create a mapping as follows…

Ext.ensible.cal.EventMappings.EmployeeName = {
    name: 'EmployeeName', //name in the store
    mapping: 'employee_name', //the server-side field name
    type: 'string'
};
Ext.ensible.cal.EventRecord.reconfigure();

Theoretically we could add as many custom field mappings as we wanted to this way. If we’re modifying a lot of the mappings it can sometimes be easier to completely override the EventMappings object and redefine it to include only fields we require. For example, if the only fields we wanted to record were a description, start time, end time and employee name then we could override the EventMappings object as follows…

Ext.ensible.cal.EventMappings = {
      EventId:                {name: 'event_id', mapping:'event_id', type:'int'},
      Description:         {name: 'description', mapping: 'description', type: 'string'},
      StartDate:            {name: 'start_date', mapping: 'start', type: 'date', dateFormat: 'c'},
      EndDate:             {name: 'end_date', mapping: 'end', type: 'date', dateFormat: 'c'},
      EmployeeName:  {name: 'employee_name', mapping: 'employee_name', type: 'string' }
};
Ext.ensible.cal.EventRecord.reconfigure();

Notice that the EventId field has also been mapped here, this is the very barebones of what you can record in an EventRecord for it to work. The EventId must also match the idProperty of the EventRecord store. If you’ve used a proxy to handle all store operations then the EventId will be used to determine which CRUD operation to perform on the record.

Sample of a Rendered Event Body containing Start Time and Title

The next objective is to override the renderer that specifies what our events look like in the calendar view. This is relatively straightforward to do once you know what method to override. Within each Calendar View we need to redefine our getEventBodyMarkup() function. The purpose of this method is to parse a template for the data in each of our events and return it. It uses place holders in the format of {FieldName} to inject the data for each event into the template body. For example, we could override the calendar’s MonthView event body template to cater for our custom mappings as follows…

 // custom override for event renderer
Ext.override(Ext.ensible.cal.MonthView, {
      getEventBodyMarkup: function(){
          this.eventBodyMarkup =
                   '{description}' +
                   'Employee: {employee_name}';
          return this.eventBodyMarkup;
      }
});

Of course, using custom fields means that we would need to override or extend the default event editor window that is bundled with Ext Calendar Pro. I found that when doing away with most of the default fields its far better to create your own interface for editing the events. We can intercept the default behaviour by picking up on the eventclick and dayclick events in the CalendarPanel.

listeners: {
      'eventclick' : function(view, rec, el){
            showEventEditWindow();
            return false;
      },
      'dayclick' : function(view, date, ad, el){
            showEventEditWindow();
            return false;
      }
}

Whilst this is a very quick and brief overview, the best way to learn more is to check out the examples here and read the API documentation. If you have any questions/suggestions, don’t hesitate to let me know.