Kris Wallsmith

Keep a trim autoloader

The symfony 1.4 autoloader works by scanning your PHP class files and remembering where each class and interface is defined, so it can magically load it when needed. This class-to-filename mapping is stored as an array in your application’s cache directory.

You can (and should) look at this array by opening this cache file in your text editor from time to time: cache/%SF_APP%/%SF_ENVIRONMENT%/config/config_autoload.yml.php. Inside you’ll see a big array with // comment headers.

<?php
// auto-generated by sfAutoloadConfigHandler
// date: 2010/10/24 05:29:41
return array(

  // sfDoctrineGuardPlugin_lib
  'pluginsfguardgroupformfilter' => '/path/to/plugins/sfDoctrineGuardPlugin/lib/filter/doctrine/PluginsfGuardGroupFormFilter.class.php',
  'pluginsfguardpermissionformfilter' => '/path/to/plugins/sfDoctrineGuardPlugin/lib/filter/doctrine/PluginsfGuardPermissionFormFilter.class.php',
  'pluginsfguarduserformfilter' => '/path/to/plugins/sfDoctrineGuardPlugin/lib/filter/doctrine/PluginsfGuardUserFormFilter.class.php',

  // ...

A few things to look for in this file:

1. You should not see any reference to libraries that have their own autoloader. This includes the symfony core classes, Swiftmailer, Zend Framework, etc. If you see references to classes from one of these libraries, your autoloader is not configured correctly.
2. You should not see any non-runtime classes.

You’ll probably need to add some configuration to accomplish that second point. For example, your tasks and Doctrine migration classes will never be involved in a runtime request, so they should not be included in the autoloader’s cache.

Configure the autoloader

Fortunately, excluding these files is easy enough using autoload.yml.

Add this file to your project…

# config/autoload.yml
autoload:
  # extend the "project" configuration block defined in the symfony core
  project:
    exclude: [vendor, symfony, model, migration, task]

Clear your cache…

$ php symfony cache:clear

Visit your site in the browser to prime the cache, and re-inspect the cached config_autoload.yml.php file. Your task and Doctrine migration classes should no longer be represented there.

Add this to your installer

The new installer mechanism in symfony 1.4 is the perfect place to add this sort of thing since you’re going to want to do it on every project. For an example of how this is done, check out commit dede92e on my GitHub symfony-installer project.

Read more

If you want to learn more about configuring the symfony 1.4 autoloader, please read through The symfony Reference Guide, specifically the section on autoload.yml.

Doctrine and MySQL integers

I just pasted this somewhere handy for my own reference. It’s the logic Doctrine uses to translate the integer data types you specify in schema.yml into a MySQL data type. If you’ve ever wondered why the length you set on an integer isn’t directly translated to the table definition used in your database, here’s why.

For example, the id columns in sfDoctrineGuardPlugin are defined as integer(4), which translates to id INT in the table definition. Where did the 4 go? Now you know…

Symfony: Denote Required Form Fields

You can checkout the full gist for this tutorial here.

The symfony form framework separates a form’s presentation and validation into two distinct collections of classes: widgets and validators. For the most part, these two codebases live happily without any knowledge of eachother. When data from the validators needs to be shown in the presentation layer, such as in the case of error messages, symfony provides the sfFormField class, which bridges this divide.

One common requirement for web forms is that required fields must be apparent to the user. Implementing this in the symfony form framework may not seem possible, because of the divide between widgets and validators, but it is in fact quite possible, and easily implemented.

This is a quick tutorial on how to do just that.

Validator, meet Widget

The first step is for the form’s validators to inform the form’s widgets which of its fields are required. We can do this by passing a array of field names to the widget schema once the form is fully configured:

The getRequiredFields() method returns a simple array of formatted field names that corresponds to those validators marked as required. It accomplishes this by recurrisively iterating through the form’s validators:

Label Formats

Once the form’s widgets know which fields are required, it’s up to the form formatter to decorate those fields accordingly. I’ve done this using an extension of the standard table formatter class:

Finally, we just add this custom formatter to our forms by adding the following to the overloaded __construct() method from above:

Your forms’ required fields should now render with labels that include the required class. Of course, you can do something different in the formatter to suit your needs, add a * or add a class to the entire row, but hopefully the implementation should now be clear.

Managing Master and Slave Database Connections with symfony and Doctrine

This is one of those things that should be much easier than it is. Since I started using Doctrine a few months ago, I’ve been impressed with how complete it is, but I can definitely see room for improvement as the project matures. Setting up read and write connections is one of those areas.

My challenge was to get the project I’m on ready to be hosted on Amazon EC2, with the help of RightScale. If your hosting on the cloud and have the funds available, check out RightScale. They have a number of server templates with best practices already implemented, and great online tutorials.

The environment I’m setting up includes one master and (potentially) multiple slave MySQL servers (setup with EBS storage). Setting up these servers was a piece of cake, thanks to the heavy lifting RightScale had done for me with their server templates and tutorials. The challenge I met was in getting symfony (1.2) and Doctrine (1.1) setup to choose the right connection for each query.

Code Slingin’ Below

The first order of business is organizing the database connections. I decided to go with a simple naming syntax and assume the master connection is named master and the slave connection names begin with slave. I added these methods to ProjectConfiguration so these connections are accessible:

Now I can easily grab the master connection by calling ProjectConfiguration::getActive()->getMasterConnection() from anywhere in my project, and get a slave connection by calling ->getSlaveConnection(). This is cool, but it turned out to be the easiest part, by far.

Smartly Forcing a Master or Slave Connection

I started with a tutorial on master and slave connections in the Doctrine documentation repository. This was easy to implement, but it’s not a complete solution. There are write queries in the Doctrine core that don’t go though either Doctrine_Query::preQuery() or Doctrine_Record::save(), so they end up using the current connection, which is usually the slave connection.

I came up with a solution, but I’m witholding judgement on how stable it is. I’m using Doctrine events to filter all queries run through Doctrine and swap out the PDO object used inside the Doctrine_Connection object with either the master or slave PDO object:

Then simply add this listener to each of you Doctrine_Connection objects by using the (undocumented?) ProjectConfiguration::configureDoctrineConnection() method:

This seems to be working for my purposes, but I feel a bit dirty hacking into Doctrine_Connection objects like this. For a brief moment as each query is run, the Doctrine_Connection object that includes the name master may in fact include a slave PDO object, and vice versa.

One More Thing

This new environment includes multiple database servers, so it naturally includes multiple load-balanced web servers, which precludes the use of sfSessionStorage because of it’s reliance on a local filesystem. I decided to go with sfPDOSessionStorage for the time being.

I was expecting to have to extend sfPDOSessionStorage to choose between master and slave connections for each storage operation. However, upon looking at the code I realized that every operation may possibly include a write query, so I just specified the master connection in factories.yml:

NOTE This configuration assumes there is always a connection named master, whereas the method in ProjectConfiguration includes a fallback to the current Doctrine connection.

Doctrine Timestamps and User Timezones

I recently added a “timezone” dropdown to the user preferences screen on a symfony application currently in development. This simple extension to the sfDoctrineRecord class makes it easy to present times from the database in the current user’s timezone.

abstract class myRecord extends sfDoctrineRecord
{
  protected function _get($fieldName, $load = true)
  {
    if ($value = parent::_get($fieldName, $load))
    {
      $column = $this->getTable()->getColumnDefinition($fieldName);
      if ($column && 'timestamp' == $column['type'])
      {
        $timezone = date_default_timezone_get();
        if (ProjectConfiguration::DEFAULT_TIMEZONE != $timezone)
        {
          // shift value to the current timezone
          date_default_timezone_set(ProjectConfiguration::DEFAULT_TIMEZONE);
          $time = strtotime($value);

          date_default_timezone_set($timezone);
          $value = date('Y-m-d H:i:s', $time);
        }
      }
    }

    return $value;
  }

  protected function _set($fieldName, $value, $load = true)
  {
    $column = $this->getTable()->getColumnDefinition($fieldName);
    if ($column && 'timestamp' == $column['type'] && $time = strtotime($value))
    {
      $timezone = date_default_timezone_get();
      if (ProjectConfiguration::DEFAULT_TIMEZONE != $timezone)
      {
        // shift value to the default timezone
        date_default_timezone_set(ProjectConfiguration::DEFAULT_TIMEZONE);
        $value = date('Y-m-d H:i:s', $time);

        date_default_timezone_set($timezone);
      }
    }

    return parent::_set($fieldName, $value, $load);
  }
}

To get sfDoctrinePlugin to use this class instead of the default, sfDoctrineRecord, add the following to your ProjectConfiguration.

// config/ProjectConfiguration.class.php
class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    // ...

    sfConfig::set('doctrine_model_builder_options', array(
      'baseClassName' => 'myRecord',
    ));
  }

  // ...
}

Two ZendCon proposals

I submitted two 400-character proposals to ZendCon yesterday.

Someone else’s symfony

Taking on development of a symfony application started by another developer can be a daunting task, especially for those not familiar with the framework. This will be a practical exploration of symfony from the perspective of a developer taking on an existing project. Topics will include getting started, automated testing, the anatomy of a symfony request, refactoring and symfony best practices.

I think this is a really juicy topic I’ve never seen covered. The current symfony documentation is geared toward either someone new to symfony starting a new project or someone experienced with symfony working on an existing project. I think the population of devs new to symfony on an existing project could use some luv. This also seems like a new and refreshing way to introduce symfony.

The Community Stack

A vital ingredient to any open source project is a vibrant community. Drawing from his experience as Community Manager for the symfony framework, Kris will examine the makeup of a successful “community stack” and propose three basic layers: devs/users, the larger OSS community, and the society as a whole. How these layers interact and grow will be the focus of this session.

The idea here is to acknowledge the importance of community in an open source project with the same significance you would any other solution stack you depend on. I’ve been working on some meat for each of those three layers, but haven’t had a chance to give this talk yet. Here’s hoping that will change!