Fabien Potencier
7 months ago
Tutorials
20

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:

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 symfony MVC framework

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 symfony MVC framework

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.

Comments

#1 Artur Martins said 40 minutes later: Wow... Excelent work guys!

#2 Markus said 44 minutes later

little typo in the very first hello world example

$disptacher has to be $dispatcher

#3 Olivier Mansour said about 1 hour later: congrats for all this work. This note show well all the work done and how it seems exciting to work with symfony 1.1.

#4 Paolovas said about 2 hours later: Good Job !

#5 Taku said about 3 hours later

Great news to see technical stuff released ! Hope to see even more in the coming weeks :)

Thanks a lot.

#6 Gummy said about 3 hours later: Holly shit, this is a fucking awesome post. Now I can say that I understand clearly how works my everyday weapon of choice.

#7 Frank Stelzer said about 6 hours later: Excellent, documentation sheet about symfony 1.1. Things getting so much clearer, after reading this article. Like always, great job!

#8 Akira said about 8 hours later: Cool! :D
Symfony is becoming a meta-framework. I'm expecting to see other teams grabbing your classes to extend their frameworks. It'll be good for the symfony community!

#9 Sebastien said about 19 hours later

great works but something goes wrong for me:

when i read "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:"
i understand that i only need sfCoreAutoload in my project to use sfYaml, but when i read the sfCoreAutoload code i see sfException and sfFinder are used and in sfException i see it use sfConfig and sfYaml (sfContext is tested for existant then no dependencies ) it is a bit more than just one class :)

perhaps i have miss something.

#10 z01d said about 19 hours later: Hey, guys, that's great, but we'll probably need some tutorials (much like Askeet did for v.1) to showcase the benefits of the new (more complex) system to the end user (your average php coder).

#11 Mark said about 19 hours later

Great work guys, I'm looking forward to using it.

I was thinking that with such massive changes to the architecture, would it be more appropriate to give it a new major version number? Version 2.0 would be a better indication of how much it has changed. Calling it version 1.1 pretends only a few new features have changed (at least, following 'usual' versioning conventions...)

#12 NiKo said 1 day later: Sebastien> You can of course just require_once the sfYaml class (and maybe the sfYamlDumper one) and use them as is in your non-symfony php project (exceptions used in these classes are the standard SPL ones).

#13 sebastien said 1 day later

niko > désolé je parle trop mal anglais, ce qe je voulais dire c'est que quand on lit le diagramme on a l'impression que sfCoreAutoload est le minimum vital nécessaire pour utilisé des classes de la platform symfony alors que c'est un petit groupe composé de sfCoreAutoload, sfFinder, sfException,sfYaml, sfConfig d'apres ce que j'ai vu du code.

#14 mdesign said 1 day later

mistake:
article source code: $routing->connect('hello', '/hello/name');

working code: $routing->connect('hello', '/hello/:name');

Great, evolving framework!
I hope the new book, and the form book will have the same quality like this post! except mistyping:)

#15 Aliakhtar said 1 day later

Excellent work !

This will really help us in understanding the whole framework.

Thanks a lot.

#16 moreilla said 1 day later: Symfony is the best framework because of its EXCELLENT documentation~Thank you~

#17 bqbtoan said 2 days later: Cool :D, good Job!

#18 Jonathan Nieto said 2 days later: Simply awesome!, great work

#19 Sebastian said 9 days later: Excellent! The modularized architecture actually eliminates my only major concern with Symfony.
Bye, bye, Zend Framework :)

#20 slantedview said 25 days later: I just discovered symfony yesterday, and I'm already so impressed that I decided to rewrite my entire site (currently built with drupal) using symfony. I might be crazy, but I can't help it. This framework looks great!

Blog