The symfony 1.1 architecture

Before we release symfony 1.1 later this week, I want to give some information about the new symfony 1.1 architecture. Apart from the new exciting features we have in symfony 1.1, this version also represents a year of hard work to refactor the internals. Let's dig into symfony internals a bit!

The symfony platform

symfony 1.1 is based on a set of cohesive but decoupled classes, the symfony platform:

Each class in the symfony platform is useable without the whole MVC architecture. The symfony platform classes have no dependency, and the only prerequisite to use them is the registration of the symfony autoloader:

require_once '/path/to/sfCoreAutoload.class.php';
sfCoreAutoload::register();
 

With just two lines of code, you can use any of the symfony platform classes. For example, if one of your projects does not use symfony, you can still use the sfYaml class by including the symfony autoloader:

require_once '/path/to/sfCoreAutoload.class.php';
sfCoreAutoload::register();
 
// load some YAML file or string
$config = sfYaml::load('/path/to/a/file.yml');
$config = sfYaml::load(<<<EOF
config:
  key: value
  foo: [bar, foobar]
  bar: { bar: foo }
EOF);
 
// dump some array to YAML
$yaml = sfYaml::dump($config);
 

The same goes for all classes, like the sfCache classes:

require_once '/path/to/sfCoreAutoload.class.php';
sfCoreAutoload::register();
 
$cache = new sfSQLiteCache(array('database' => dirname(__FILE__).'/cache.db'));
$cache->set('foo', 'bar');
$value = $cache->get('foo');
 

This example uses the SQLite backend but symfony also provides backends based on File, APC, XCache, EACcelerator, and Memcache.

Even if it seems natural to use those classes independently, the symfony platform goes one step further with classes like sfRequest or sfResponse. Let's see an example where we use these two classes to create a simple 'Hello World' script:

require_once '/path/to/sfCoreAutoload.class.php';
sfCoreAutoload::register();
 
$dispatcher = new sfEventDispatcher();
 
$request = new sfWebRequest($dispatcher);
$response = new sfWebResponse($dispatcher);
 
$content = 'Hello '.$request->getParameter('name', 'World');
 
$response->setContent($content);
$response->send();
 

In this example, we use a sfEventDispatcher object. Even if the platform classes are totally decoupled, some classes can communicate together thanks to the dispatcher. The dispatcher provides a mean to notify events and to listen to these events. You do not need to implement an interface to create a listener, nor use any specific base class to create an event; an event is only defined by its name and by the array of parameters sent by the notifier.

For example, the sfPatternRouting class listens to the request.filter_parameters event:

$callback = array($this, 'filterParameters');
$dispatcher->connect('request.filter_parameters', $callback);
 

And when a request is created, the sfWebRequest notifies the request.filter_parameters event:

$event = new sfEvent($this, 'request.filter_parameters');
$parameters = $dispatcher->filter($event, $parameters);
 

So, even if the sfWebRequest class and the sfPatternRouting class are decoupled, they automagically communicate together when they share the same dispatcher.

To illustrate this feature, let's change the previous example a bit by adding a routing object that connects the /hello/:name pattern to the 'Hello World' application:

require_once '/path/to/sfCoreAutoload.class.php';
sfCoreAutoload::register();
 
$dispatcher = new sfEventDispatcher();
 
$routing = new sfPatternRouting($dispatcher);
$routing->connect('hello', '/hello/:name');
 
$request = new sfWebRequest($dispatcher);
$response = new sfWebResponse($dispatcher);
 
$content = 'Hello '.$request->getParameter('name', 'World');
 
$response->setContent($content);
$response->send();
 

Now, if you save this script as index.php under the web root directory, you can access the application by typing something like /index.php/hello/Fabien in your browser.

This is great if you want to leverage some of the cool features symfony provides, without using the whole MVC architecture.

This is also a great way to migrate your old applications to symfony. Instead of rewriting your applications from scratch, you can introduce symfony concepts one at a time.

You can also create your very own framework on top of the symfony platform. You do not need to reinvent the wheel, the symfony platform has all you need to create a great framework:

• sfRequest/sfRouting: The request
• sfUser/sfStorage: The user/session
• sfForm: The form framework
• sfCache: The cache framework
• sfOutputEscaper: The XSS protection layer
• sfResponse: The response
• ...

Of course, the symfony framework itself is powered by the symfony platform:

The sfConfiguration class provides a way to configure and to customize your applications. The sfContext class acts as a registry that holds references to all core objects. And thanks to the factories.yml configuration file, you can customize all the registry classes very easily, just by editing a YAML file.

The symfony MVC framework is provided by a set of additional classes on top of the symfony framework as shown below:

The Model layer is provided by third-party libraries, Propel or Doctrine. Even if symfony 1.1 is bundled with the Propel plugin, it's very easy to switch to Doctrine by installing the sfDoctrinePlugin. Both ORMs provide the same level of integration with symfony.

The View layer is provided by the sfView class, a bunch of helpers, and templates written by the developer.

The Controller layer is based on a filter chain and actions defined by the developer.

As of version 1.1, symfony is one of the most decoupled framework available in PHP, even more than the Zend Framework. For example, the sfForm framework is useable without any of the MVC classes whereas Zend_Form is somewhat tied to the controller and the view layers.