How Symfony2 Differs from Symfony1

Directory Structure¶

When looking at a Symfony2 project - for example, the Symfony2 Standard Edition - you’ll notice a very different directory structure than in symfony1. The differences, however, are somewhat superficial.

$ php app/console assets:install web

Autoloading¶

One of the advantages of modern frameworks is never needing to worry about requiring files. By making use of an autoloader, you can refer to any class in your project and trust that it’s available. Autoloading has changed in Symfony2 to be more universal, faster, and independent of needing to clear your cache.

In symfony1, autoloading was done by searching the entire project for the presence of PHP class files and caching this information in a giant array. That array told symfony1 exactly which file contained each class. In the production environment, this caused you to need to clear the cache when classes were added or moved.

In Symfony2, a tool named Composer handles this process. The idea behind the autoloader is simple: the name of your class (including the namespace) must match up with the path to the file containing that class. Take the FrameworkExtraBundle from the Symfony2 Standard Edition as an example:

namespace SensioBundleFrameworkExtraBundle;

use SymfonyComponentHttpKernelBundleBundle;
// ...

class SensioFrameworkExtraBundle extends Bundle
{
    // ...
}

The file itself lives at vendor/sensio/framework-extra-bundle/Sensio/Bundle/FrameworkExtraBundle/SensioFrameworkExtraBundle.php. As you can see, the second part of the path follows the namespace of the class. The first part is equal to the package name of the SensioFrameworkExtraBundle.

The namespace, SensioBundleFrameworkExtraBundle, and package name, sensio/framework-extra-bundle, spells out the directory that the file should live in (vendor/sensio/framework-extra-bundle/Sensio/Bundle/FrameworkExtraBundle/). Composer can then look for the file at this specific place and load it very fast.

If the file did not live at this exact location, you’d receive a Class "SensioBundleFrameworkExtraBundleSensioFrameworkExtraBundle" does not exist. error. In Symfony2, a “class does not exist” error means that the namespace of the class and physical location do not match. Basically, Symfony2 is looking in one exact location for that class, but that location doesn’t exist (or contains a different class). In order for a class to be autoloaded, you never need to clear your cache in Symfony2.

As mentioned before, for the autoloader to work, it needs to know that the Sensio namespace lives in the vendor/sensio/framework-extra-bundle directory and that, for example, the Doctrine namespace lives in the vendor/doctrine/orm/lib/ directory. This mapping is entirely controlled by Composer. Each third-party library you load through Composer has its settings defined and Composer takes care of everything for you.

For this to work, all third-party libraries used by your project must be defined in the composer.json file.

If you look at the HelloController from the Symfony2 Standard Edition you can see that it lives in the AcmeDemoBundleController namespace. Yet, the AcmeDemoBundle is not defined in your composer.json file. Nonetheless are the files autoloaded. This is because you can tell Composer to autoload files from specific directories without defining a dependency:

"autoload": {
    "psr-0": { "": "src/" }
}

This means that if a class is not found in the vendor directory, Composer will search in the src directory before throwing a “class does not exist” exception. Read more about configuring the Composer autoloader in the Composer documentation.

Using the Console¶

In symfony1, the console is in the root directory of your project and is called symfony:

$ php symfony

In Symfony2, the console is now in the app sub-directory and is called console:

$ php app/console

Applications¶

In a symfony1 project, it is common to have several applications: one for the frontend and one for the backend for instance.

In a Symfony2 project, you only need to create one application (a blog application, an intranet application, ...). Most of the time, if you want to create a second application, you might instead create another project and share some bundles between them.

And if you need to separate the frontend and the backend features of some bundles, you can create sub-namespaces for controllers, sub-directories for templates, different semantic configurations, separate routing configurations, and so on.

Of course, there’s nothing wrong with having multiple applications in your project, that’s entirely up to you. A second application would mean a new directory, e.g. my_app/, with the same basic setup as the app/ directory.

Bundles and Plugins¶

In a symfony1 project, a plugin could contain configuration, modules, PHP libraries, assets and anything else related to your project. In Symfony2, the idea of a plugin is replaced by the “bundle”. A bundle is even more powerful than a plugin because the core Symfony2 framework is brought in via a series of bundles. In Symfony2, bundles are first-class citizens that are so flexible that even core code itself is a bundle.

In symfony1, a plugin must be enabled inside the ProjectConfiguration class:

// config/ProjectConfiguration.class.php
public function setup()
{
    // some plugins here
    $this->enableAllPluginsExcept(array(...));
}

In Symfony2, the bundles are activated inside the application kernel:

// app/AppKernel.php
public function registerBundles()
{
    $bundles = array(
        new SymfonyBundleFrameworkBundleFrameworkBundle(),
        new SymfonyBundleTwigBundleTwigBundle(),
        ...,
        new AcmeDemoBundleAcmeDemoBundle(),
    );

    return $bundles;
}

# some app.yml file from symfony1
all:
  email:
    from_address:  foo.bar@example.com

public function helloAction($name)
{
    $fromAddress = $this->container->getParameter('email.from_address');
}