My RSS » Items by Fabien Potencier

Items by Fabien Potencier

Planet PHP

Create your own framework... on top of the Symfony2 Components (part 12)

Posted: January 24th, 2012, 11:39pm MST by Fabien Potencier

This article is part of a series of articles that explains how to create a framework with the Symfony2 Components: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12.

In the last installment of this series, we have emptied the Simplex\\Framework class by extending the HttpKernel class from Symfony. Seeing this empty class, you might be tempted to move some code from the front controller to it:

<?php
 
// example.com/src/Simplex/Framework.php
 
namespace Simplex;
 
use Symfony\Component [HttpKernel\HttpKernel;] use Symfony\Component\Routing;
use Symfony\Component [HttpKernel;] use Symfony\Component\EventDispatcher\EventDispatcher;
 
class Framework extends [HttpKernel] {
    public function __construct($routes)
    {
        $context = new Routing\RequestContext();
        $matcher = new Routing\Matcher\UrlMatcher($routes, $context);
        $resolver = new [HttpKernel\Controller\ControllerResolver();]  
        $dispatcher = new EventDispatcher();
        $dispatcher->addSubscriber(new [HttpKernel\EventListener\RouterListener(] matcher));
        $dispatcher->addSubscriber(new [HttpKernel\EventListener\ResponseListener('UTF-8'));]  
        parent::__construct($dispatcher, $resolver);
    }
}

The front controller code would become more concise:

<?php
 
// example.com/web/front.php
 
require_once __DIR__.'/../vendor/.composer/autoload.php';
 
use Symfony\Component [HttpFoundation\Request;]  
$request = Request::createFromGlobals();
$routes = include __DIR__.'/../src/app.php';
 
$framework = new Simplex\Framework($routes);

Truncated by Planet PHP, read more at the original (another 18437 bytes)

Create your own framework... on top of the Symfony2 Components (part 11)

Posted: January 23rd, 2012, 5:51am MST by Fabien Potencier
This article is part of a series of articles that explains how to create a framework with the Symfony2 Components: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12.

If you were to use our framework right now, you would probably have to add support for custom error messages. Right now, we have 404 and 500 error support but the responses are hardcoded in the framework itself. Making them customizable is easy enough though: dispatch a new event and listen to it. Doing it right means that the listener has to call a regular controller. But what if the error controller throws an exception? You will end up in an infinite loop. There should be an easier way, right?

Enter the HttpKernel class. Instead of solving the same problem over and over again and instead of reinventing the wheel each time, the HttpKernel class is a generic, extensible, and flexible implementation of HttpKernelInterface.

This class is very similar to the framework class we have written so far: it dispatches events at some strategic points during the handling of the request, it uses a controller resolver to choose the controller to dispatch the request to, and as an added bonus, it takes care of edge cases and provides great feedback when a problem arises.

Here is the new framework code:
```
<?php
 
// example.com/src/Simplex/Framework.php
 
namespace Simplex;
 
use Symfony\Component [HttpKernel\HttpKernel;]  
class Framework extends [HttpKernel] {
}
 
```
And the new front controller:
```
<?php
 
// example.com/web/front.php
 
require_once __DIR__.'/../vendor/.composer/autoload.php';
 
use Symfony\Component [HttpFoundation\Request;] use Symfony\Component [HttpFoundation\Response;] use Symfony\Component\Routing;
use Symfony\Component [HttpKernel;] use Symfony\Component\EventDispatcher\EventDispatcher;
 
$request = Request::createFromGlobals();
$routes = include __DIR__.'/../src/app.php';
 
$context = new Routing\RequestContext();
$matcher = new Routing\Matcher\UrlMatcher($routes, $context);
$resolver = new [HttpKernel\Controller\ControllerResolver();]  
$dispatcher = new EventDispatcher();
$dispatcher->addSubscriber(new [HttpKernel\EventListener\RouterListener(] matcher));
 
```
Truncated by Planet PHP, read more at the original (another 11484 bytes)
Create your own framework... on top of the Symfony2 Components (part 10)

Posted: January 21st, 2012, 12:43am MST by Fabien Potencier
In the conclusion of the second part of this series, I've talked about one great benefit of using the Symfony2 components: the interoperability between all frameworks and applications using them. Let's do a big step towards this goal by making our framework implement HttpKernelInterface:
```
namespace Symfony\Component [HttpKernel;]  
interface [HttpKernelInterface] {
    /**
     * @return Response A Response instance
     */
    function handle(Request $request, $type = self::MASTER_REQUEST, $catch = true);
}
 
```
HttpKernelInterface is probably the most important piece of code in the [HttpKernel] component, no kidding. Frameworks and applications that implement this interface are fully interoperable. Moreover, a lot of great features will come with it for free.

Update your framework so that it implements this interface:
```
<?php
 
// example.com/src/Framework.php
 
// ...
 
use Symfony\Component [HttpKernel\HttpKernelInterface;]  
class Framework implements [HttpKernelInterface] {
    // ...
 
    public function handle(Request $request, $type = [HttpKernelInterface::MASTER_REQUEST,] $catch = true)
    {
        // ...
    }
}
 
```
Even if this change looks trivial, it brings us a lot! Let's talk about one of the most impressive one: transparent HTTP caching support.

The HttpCache class implements a fully-featured reverse proxy, written in PHP; it implements HttpKernelInterface and wraps another HttpKernelInterface instance:
```
// example.com/web/front.php
 
use Symfony\Component [HttpKernel\HttpCache\HttpCache;] use Symfony\Component [HttpKernel\HttpCache\Store;]  
$framework = new Simplex\Framework($dispatcher, $matcher, $resolver);
$framework = new [HttpCache(] framework, new Store(__DIR__.'/../cache'));
 
$framework->handle($request)->send();
 
```
That's all it takes to add HTTP caching support to our framework. Isn't it amazing?

Configuring the cache needs to be done via HTTP cache headers. For instance, to cache a response for 10 seconds, use the Response::setTtl() method::
```
// example.com/src/Calendar/Controller/LeapYearController.php
 
public function indexAction(Request $request, $year)
{
    $leapyear = new LeapYear();
    if ($leapyear->isLeapYear($year)) {
        $response = new Response('Yep, this is a leap year!');
    } else {
        $response = new Response"/>
```
Truncated by Planet PHP, read more at the original (another 8450 bytes)
Create your own framework... on top of the Symfony2 Components (part 9)

Posted: January 19th, 2012, 5:09am MST by Fabien Potencier
Our framework is still missing a major characteristic of any good framework: extensibility. Being extensible means that the developer should be able to easily hook into the framework life cycle to modify the way the request is handled.

What kind of hooks are we talking about? Authentication or caching for instance. To be flexible, hooks must be plug-and-play; the ones you "register" for an application are different from the next one depending on your specific needs. Many software have a similar concept like Drupal or Wordpress. In some languages, there is even a standard like WSGI in Python or Rack in Ruby.

As there is no standard for PHP, we are going to use a well-known design pattern, the Observer, to allow any kind of behaviors to be attached to our framework; the Symfony2 EventDispatcher Component implements a lightweight version of this pattern:
```
{
    "require": {
        "symfony/class-loader": "2.1.*",
        "symfony/http-foundation": "2.1.*",
        "symfony/routing": "2.1.*",
        "symfony/http-kernel": "2.1.*",
        "symfony/event-dispatcher": "2.1.*"
    },
    "autoload": {
        "psr-0": { "Simplex": "src/", "Calendar": "src/" }
    }
}
 
```
How does it work? The dispatcher, the central object of the event dispatcher system, notifies listeners of an event dispatched to it. Put another way: your code dispatches an event to the dispatcher, the dispatcher notifies all registered listeners for the event, and each listener do whatever it wants with the event.

As an example, let's create a listener that transparently adds the Google Analytics code to all responses.

To make it work, the framework must dispatch an event just before returning the Response instance:
```
<?php
 
// example.com/src/Simplex/Framework.php
 
namespace Simplex;
 
use Symfony\Component [HttpFoundation\Request;] use Symfony\Component [HttpFoundation\Response;] use Symfony\Component\Routing\Matcher\UrlMatcherInterface;
use Symfony\Component\Routing\Exception\ResourceNotFoundException;
use Symfony\Component [HttpKernel\Controller\ControllerResolverInterface;] use Symfony\Component\EventDispatcher\EventDispatcher;
 
class Framework
{
    protected $matcher;
    protected $resolver;
    protected $dispatcher;
 
    public function __construct(EventDispatcher $dispatcher, UrlMatcherInterface $matcher, ControllerResolverInterface $resolver)
    {
        $this->matcher = $matcher;
        $this->resolver = $resolver;
        $this->dispatcher = $dispatcher;
    }
 
    public function handle(Request $request)
    {
        try {
            $request->attributes->add($this->matcher->match($request->getPathInfo())
```
Truncated by Planet PHP, read more at the original (another 22435 bytes)

Create your own framework... on top of the Symfony2 Components (part 8)

Posted: January 17th, 2012, 2:39am MST by Fabien Potencier

Some watchful readers pointed out some subtle but nonetheless important bugs in the framework we have built yesterday. When creating a framework, you must be sure that it behaves as advertised. If not, all the applications based on it will exhibit the same bugs. The good news is that whenever you fix a bug, you are fixing a bunch of applications too.

Today's mission is to write unit tests for the framework we have created by using PHPUnit. Create a PHPUnit configuration file in example.com/phpunit.xml.dist:

<?xml version="1.0" encoding="UTF-8"?>
 
<phpunit backupGlobals="false"
         backupStaticAttributes="false"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         processIsolation="false"
         stopOnFailure="false"
         syntaxCheck="false"
         bootstrap="vendor/.composer/autoload.php"
>
    <testsuites>
        <testsuite name="Test Suite">
            <directory>./tests</directory>
        </testsuite>
    </testsuites>
</phpunit>

This configuration defines sensible defaults for most PHPUnit settings; more interesting, the autoloader is used to bootstrap the tests, and tests will be stored under the example.com/tests/ directory.

Now, let's write a test for "not found" resources. To avoid the creation of all dependencies when writing tests and to really just unit-test what we want, we are going to use test doubles. Test doubles are easier to create when we rely on interfaces instead of concrete classes. Fortunately, Symfony2 provides such interfaces for core objects like the URL matcher and the controller resolver. Modify the framework to make use of them:

<?php
 
// example.com/src/Simplex/Framework.php
 
namespace Simplex;
 
// ...
 
use Symfony\Component\Routing\Matcher\UrlMatcherInterface;
use Symfony\Component [HttpKernel\Controller\ControllerResolverInterface;]  
class Framework
{
    protected $matcher;
    protected $resolver;
 
    public function __construct(UrlMatcherInterface $matcher, ControllerResolverInterface $resolver)
    {
        $this->matcher = $matcher;
        $this->resolver = $resolver;
    }
 
    // ...
}

We are now ready to write our first test:

<?php
 
// example.com/tests/Simplex/Tests/FrameworkTest.php
 
namespace Simplex\Tests;
 
use Simplex\Framework;
use Symfony\Component [HttpFoundation\Request;] use Symfony\Component\Routing\Exception\ResourceNotFoundException;
 
class FrameworkTest extends \PHPUnit_Framework_TestCase
{
    public function testNotFoundHandling()
    {
        $framework = $this->getFrameworkForException(new ResourceNotFoundException());
 
        $response = $framework->handle(new Request());
 
        $this->assertEqual

Truncated by Planet PHP, read more at the original (another 8958 bytes)

Create your own framework... on top of the Symfony2 Components (part 7)

Posted: January 15th, 2012, 2:53am MST by Fabien Potencier

One down-side of our framework right now is that we need to copy and paste the code in front.php each time we create a new website. 40 lines of code is not that much, but it would be nice if we could wrap this code into a proper class. It would bring us better reusability and easier testing to name just a few benefits.

If you have a closer look at the code, front.php has one input, the Request, and one output, the Response. Our framework class will follow this simple principle: the logic is about creating the Response associated with a Request.

As the Symfony2 components requires PHP 5.3, let's create our very own namespace for our framework: Simplex.

Move the request handling logic into its own Simplex\Framework class:

<?php
 
// example.com/src/Simplex/Framework.php
 
namespace Simplex;
 
use Symfony\Component [HttpFoundation\Request;] use Symfony\Component [HttpFoundation\Response;] use Symfony\Component\Routing\Matcher\UrlMatcher;
use Symfony\Component\Routing\Exception\ResourceNotFoundException;
use Symfony\Component [HttpKernel\Controller\ControllerResolver;]  
class Framework
{
    protected $matcher;
    protected $resolver;
 
    public function __construct(UrlMatcher $matcher, ControllerResolver $resolver)
    {
        $this->matcher = $matcher;
        $this->resolver = $resolver;
    }
 
    public function handle(Request $request)
    {
        try {
            $request->attributes->add($this->matcher->match($request->getPathInfo()));
 
            $controller = $this->resolver->getController($request);
            $arguments = $this->resolver->getArguments($request, $controller);
 
            return call_user_func_array($controller, $arguments);
        } catch (ResourceNotFoundException $e) {
            return new Response('Not Found', 404);
        } catch (\Exception $e) {
            return new Response('An error occurred', 500);
        }
    }
}

And update example.com/web/front.php accordingly:

<?php
 
// example.com/web/front.php
 
// ...
 
$request = Request::createFromGlobals();
$routes = include __DIR__.'/../src/app.php';

Truncated by Planet PHP, read more at the original (another 8017 bytes)

Create your own framework... on top of the Symfony2 Components (part 6)

Posted: January 13th, 2012, 3:14am MST by Fabien Potencier
You might think that our framework is already pretty solid and you are probably right. But let's see how we can improve it nonetheless.

Right now, all our examples use procedural code, but remember that controllers can be any valid PHP callbacks. Let's convert our controller to a proper class:
```
class LeapYearController
{
    public function indexAction($request)
    {
        if (is_leap_year($request->attributes->get('year'))) {
            return new Response('Yep, this is a leap year!');
        }
 
        return new Response('Nope, this is not a leap year.');
    }
}
 
```
Update the route definition accordingly:
```
$routes->add('leap_year', new Routing\Route('/is_leap_year/{year}', array(
    'year' => null,
    '_controller' => array(new LeapYearController(), 'indexAction'),
)));
 
```
The move is pretty straightforward and makes a lot of sense as soon as you create more pages but you might have noticed a non-desirable side-effect... The LeapYearController class is always instantiated, even if the requested URL does not match the leap_year route. This is bad for one main reason: performance wise, all controllers for all routes must now be instantiated for every request. It would be better if controllers were lazy-loaded so that only the controller associated with the matched route is instantiated.

To solve this issue, and a bunch more, let's install and use the [HttpKernel] component:
```
{
    "require": {
        "symfony/class-loader": "2.1.*",
        "symfony/http-foundation": "2.1.*",
        "symfony/routing": "2.1.*",
        "symfony/http-kernel": "2.1.*"
    }
}
 
```
The [HttpKernel] component has many interesting features, but the one we need right now is the controller resolver. A controller resolver knows how to determine the controller to execute and the arguments to pass to it, based on a Request object. All controller resolvers implement the following interface:
```
namespace Symfony\Component [HttpKernel\Controller;]  
interface ControllerResolverInterface
{
    function getController(Request $request);
 
    function getArguments(Request $request, $controller);
}
 
```
The getController() method relies on the same convention as the one we have defined earlier: the _controller request attribute must contain the controller associated with the Request. Besides the built-in PHP callbacks, getController() also supports strings composed of a class name fo
Truncated by Planet PHP, read more at the original (another 11492 bytes)
Create your own framework... on top of the Symfony2 Components (part 5)

Posted: January 11th, 2012, 7:02am MST by Fabien Potencier
The astute reader has noticed that our framework hardcodes the way specific "code" (the templates) is run. For simple pages like the ones we have created so far, that's not a problem, but if you want to add more logic, you would be forced to put the logic into the template itself, which is probably not a good idea, especially if you still have the separation of concerns principle in mind.

Let's separate the template code from the logic by adding a new layer: the controller: The controller mission is to generate a Response based on the information conveyed by the client Request.

Change the template rendering part of the framework to read as follows:
```
<?php
 
// example.com/web/front.php
 
// ...
 
try {
    $request->attributes->add($matcher->match($request->getPathInfo()));
    $response = call_user_func('render_template', $request);
} catch (Routing\Exception\ResourceNotFoundException $e) {
    $response = new Response('Not Found', 404);
} catch (Exception $e) {
    $response = new Response('An error occurred', 500);
}
 
```
As the rendering is now done by an external function (render_template() here), we need to pass to it the attributes extracted from the URL. We could have passed them as an additional argument to render_template(), but instead, let's use another feature of the Request class called attributes: Request attributes lets you attach additional information about the Request that is not directly related to the HTTP Request data.

You can now create the render_template() function, a generic controller that renders a template when there is no specific logic. To keep the same template as before, request attributes are extracted before the template is rendered:
```
function render_template($request)
{
    extract($request->attributes->all(), EXTR_SKIP);
    ob_start();
    include sprintf(__DIR__.'/../src/pages/%s.php', $_route);
 
    return new Response(ob_get_clean());
}
 
```
As render_template is used as an argument to the PHP call_user_func() function, we can replace it with any valid PHP callbacks. This allows us to use a function, an anonymous function, or a method of a class as a controller... your choice.

As a convention, for each route, the associated controller is configured via the _controller route attribute:
```
$routes->add('he
```
Truncated by Planet PHP, read more at the original (another 13773 bytes)
Create your own framework... on top of the Symfony2 Components (part 4)

Posted: January 9th, 2012, 1:27am MST by Fabien Potencier
Before we start with today's topic, let's refactor our current framework just a little to make templates even more readable:
```
<?php
 
// example.com/web/front.php
 
require_once __DIR__.'/../src/autoload.php';
 
use Symfony\Component [HttpFoundation\Request;] use Symfony\Component [HttpFoundation\Response;]  
$request = Request::createFromGlobals();
 
$map = array(
    '/hello' => 'hello',
    '/bye'   => 'bye',
);
 
$path = $request->getPathInfo();
if (isset($map[$path])) {
    ob_start();
    extract($request->query->all(), EXTR_SKIP);
    include sprintf(__DIR__.'/../src/pages/%s.php', $map[$path]);
    $response = new Response(ob_get_clean());
} else {
    $response = new Response('Not Found', 404);
}
 
$response->send();
 
```
As we now extract the request query parameters, simplify the hello.php template as follows:
```

 
Hello <?php echo htmlspecialchars($name, ENT_QUOTES, 'UTF-8') ?>
 
```
Now, we are in good shape to add new features.

One very important aspect of any website is the form of its URLs. Thanks to the URL map, we have decoupled the URL from the code that generates the associated response, but it is not yet flexible enough. For instance, we might want to support dynamic paths to allow embedding data directly into the URL instead of relying on a query string:
```
# Before
/hello?name=Fabien
 
# After
/hello/Fabien
 
```
To support this feature, we are going to use the Symfony2 Routing component. As always, add it to composer.json and run the php composer.phar update command to install it:
```
{
    "require": {
        "symfony/class-loader": "2.1.*",
        "symfony/http-foundation": "2.1.*",
        "symfony/routing": "2.1.*"
    }
}
 
```
From now on, we are going to use the generated Composer autoloader inste
Truncated by Planet PHP, read more at the original (another 14824 bytes)
Create your own framework... on top of the Symfony2 Components (part 3)

Posted: January 7th, 2012, 10:41am MST by Fabien Potencier
Up until now, our application is simplistic as there is only one page. To spice things up a little bit, let's go crazy and add another page that says goodbye:
```
<?php
 
// framework/bye.php
 
require_once __DIR__.'/autoload.php';
 
use Symfony\Component [HttpFoundation\Request;] use Symfony\Component [HttpFoundation\Response;]  
$request = Request::createFromGlobals();
 
$response = new Response('Goodbye!');
$response->send();
 
```
As you can see for yourself, much of the code is exactly the same as the one we have written for the first page. Let's extract the common code that we can share between all our pages. Code sharing sounds like a good plan to create our first "real" framework!

The PHP way of doing the refactoring would probably be the creation of an include file:
```
<?php
 
// framework/init.php
 
require_once __DIR__.'/autoload.php';
 
use Symfony\Component [HttpFoundation\Request;] use Symfony\Component [HttpFoundation\Response;]  
$request = Request::createFromGlobals();
$response = new Response();
 
```
Let's see it in action:
```
<?php
 
// framework/index.php
 
require_once __DIR__.'/init.php';
 
$input = $request->get('name', 'World');
 
$response->setContent(sprintf('Hello %s', htmlspecialchars($input, ENT_QUOTES, 'UTF-8')));
$response->send();
 
```
And for the "Goodbye" page:
```
<?php
 
// framework/bye.php
 
require_once __DIR__.'/init.php';
 
$response->setContent('Goodbye!');
$response->send();
 
```
We have indeed moved most of the shared code into a central place, but it does not feel like a good abstraction, doesn't it? First, we still have the send() method in all pages, then our pages does not look like templates, and we are still not able to test this code properly.

Moreover, adding a new page means that we need to create a new PHP script, which name is exposed to the end user via the URL (http://example.com/bye.php): there is a direct mapping between the PHP script name and the client URL. This is because the dispatching of the request is done by the web server directly. It might be a good idea to move this dispatching to our code for better flexibility. This can be easily achieved by routing all client requests to a single PHP script.

Exposing a single PHP script to the end user is a design pattern called the "front controller".

Such a script might look like the following:
```
<?php
 
// framework/front.php
 
require_once __DIR__.'/autoload.php';
 
use Symfony\Component [HttpFoundation\Request;] use Symfony\Co
```
Truncated by Planet PHP, read more at the original (another 11323 bytes)
Create your own framework... on top of the Symfony2 Components (part 2)

Posted: January 5th, 2012, 3:57am MST by Fabien Potencier
Before we dive into the code refactoring, I first want to step back and take a look at why you would like to use a framework instead of keeping your plain-old PHP applications as is. Why using a framework is actually a good idea, even for the simplest snippet of code and why creating your framework on top of the Symfony2 components is better than creating a framework from scratch.

I won't talk about the obvious and traditional benefits of using a framework when working on big applications with more than a few developers; the Internet has already plenty of good resources on that topic.

Even if the "application" we wrote yesterday was simple enough, it suffers from a few problems:
```
<?php
 
// framework/index.php
 
$input = $_GET['name'];
 
printf('Hello %s', $input);
 
```
First, if the name query parameter is not given in the URL query string, you will get a PHP warning; so let's fix it:
```
<?php
 
// framework/index.php
 
$input = isset($_GET['name']) ? $_GET['name'] : 'World';
 
printf('Hello %s', $input);
 
```
Then, this application is not secure. Can you believe it? Even this simple snippet of PHP code is vulnerable to one of the most widespread Internet security issue, XSS (Cross-Site Scripting). Here is a more secure version:
```
<?php
 
$input = isset($_GET['name']) ? $_GET['name'] : 'World';
 
header('Content-Type: text/html; charset=utf-8');
 
printf('Hello %s', htmlspecialchars($input, ENT_QUOTES, 'UTF-8'));
 
```
As you might have noticed, securing your code with htmlspecialchars is tedious and error prone. That's one of the reasons why using a template engine like Twig, where auto-escaping is enabled by default, might be a good idea (and explicit escaping is also less painful with the usage of a simple e filter).

As you can see for yourself, the simple code we had written first is not that simple anymore if we want to avoid PHP warnings/notices and make the code more secure.

Beyond security, this code is not even easily testable. Even if there is not much to test, it strikes me that writing unit tests for the simplest possible snippet of PHP code is not natural and feels ugly. Here is a tentative PHPUnit unit test for the above code:
```
<?php
 
// framework/test.php
 
class IndexTest extends \PHPUnit_Framework_TestCase
{
    public function testHello()
    {
        $_GET['name'] = 'Fabien
```
Truncated by Planet PHP, read more at the original (another 16397 bytes)
Create your own framework... on top of the Symfony2 Components (part 1)

Posted: January 3rd, 2012, 3:03pm MST by Fabien Potencier
Symfony2 is a reusable set of standalone, decoupled, and cohesive PHP components that solve common web development problems.

Instead of using these low-level components, you can use the ready-to-be-used Symfony2 full-stack web framework, which is based on these components... or you can create your very own framework. This series is about the latter.

If you just want to use the Symfony2 full-stack framework, you'd better read its official documentation instead.

Why would you like to create your own framework?
Why would you like to create your own framework in the first place? If you look around, everybody will tell you that it's a bad thing to reinvent the wheel and that you'd better choose an existing framework and forget about creating your own altogether. Most of the time, they are right but I can think of a few good reasons to start creating your own framework:
- To learn more about the low level architecture of modern web frameworks in general and about the Symfony2 full-stack framework internals in particular;
- To create a framework tailored to your very specific needs (just be sure first that your needs are really specific);
- To experiment creating a framework for fun (in a learn-and-throw-away approach);
- To refactor an old/existing application that needs a good dose of recent web development best practices;
- To prove the world that you can actually create a framework on your own (... but with little effort).
I will gently guide you through the creation of a web framework, one step at a time. At each step, you will have a fully-working framework that you can use as is or as a start for your very own. We will start with simple frameworks and more features will be added with time. Eventually, you will have a fully-featured full-stack web framework.

And of course, each step will be the occasion to learn more about some of the Symfony2 Components.

If you don't have time to read the whole series, or if you want to get started fast, you can also have a look at Silex, a micro-framework based on the Symfony2 Components. The code is rather slim and it leverages many aspects of the Symfony2 Components.

Many modern web frameworks call themselves MVC frameworks. We won't talk about MVC here as the Symfony2 Components are able to create any type of frameworks, not just the ones that follow the MVC architecture. Anyway, if you have a look at the MVC semantics, this series is about how to create the Controller part of a framework. For the Model and the View, it really depends on your personal taste and I will let you use any existing third-party libraries (Doctrine, Propel, or plain-old PDO for the Model; PHP or Twig for the View).

When creating a framework, following the MVC pattern is not the right goal. The main goal should be the Separation of Concerns; I actually think that this is the only design pattern that you should really care about. The fundamental principles of the Symfony2 Components are centered around the HTTP specification. As such, the frameworks that we are going to create should be more accurately labelled as HTTP frameworks or Request/Response frameworks.
Before we start
Reading about how to create a framework is not enough. You will have to follow along and actually type all the examples we will work on. For that, you need a recent version of PHP (5.3.8 or later is good enough), a web server (like Apache or NGinx), a good knowledge of PHP and an understanding of Object Oriented programming.

Ready to go? Let's start.
Bootstrapping
Before we can even think of creating our first framework, we need to talk about some conventions: where we will store our code, how we will name our classes, how we will reference external dependencies, etc.

To store our framework, create a directory somewhere on your machine:
```
$ mkdir framework
$ cd framework
```
Coding Standards
Before anyone starts a flame war about coding standards and why the one used here suck hard, let's all admit that this does not matter that much as long as you are consistent. For this book, we are going to use the Symfony2 Coding Standards.
Components Installation
To install the Symfony2 Components that we need for our framework, we are going to use Composer, a project dependency manager for PHP. First, list your dependencies in a composer.json file:
```
{
    "require&quo
```
Truncated by Planet PHP, read more at the original (another 4027 bytes)
What is Symfony2?

Posted: October 25th, 2011, 1:48am MDT by Fabien Potencier

Last week, I held a keynote presentation about Symfony2 at the Symfony Day conference in Cologne. Many people asked me for the slides, but they were quite empty and not that useful. This blog post is more or less what I've said during the first part of the talk.
What is Symfony2?
When I ask people what Symfony2 is for them, most of them say something along the lines of: Symfony2 is a full-stack web framework written in PHP. Some also add that this is an MVC framework. And some others add that this is a decoupled framework. This is all fine and correct. But my definition is a bit different. Let me tell you what it is and why I think it matters.

Symfony2 is really about two different things.

First, Symfony2 is a reusable set of standalone, decoupled, and cohesive PHP components that solve common web development problems.

Then, based on these components, Symfony2 is also a full-stack web framework.

Depending on your project and depending on your needs, you can either pick and choose some of the Symfony2 components and start your project with them, or you can use the full-stack framework and benefit from the tight integration it provides out of the box. And choosing between the two different approaches is really up to you.
Is Symfony2 an MVC framework?
If you look around, every single framework seems to implement the MVC pattern. And most of them are advertised as MVC frameworks... but not Symfony2. Have a look at the documentation, and you will see that the MVC pattern is only mentioned once or twice, but Symfony2 is never defined as being an MVC framework. Why?

Because I really don't care whether Symfony2 is MVC or not. Probably because the MVC word is so overloaded and because nobody implements exactly the same MVC pattern anyway. The separation of concerns is all I care about. And if you like to call Symfony2 an MVC framework, then you should know that Symfony2 is really about providing the tools for the Controller part, the View part, but not the Model part. It's up to you to create your model by hand or use any other tool, like an ORM. Of course, tight integration exists for the most well known ORMs like Doctrine2 and Propel; but they are optional dependencies. The Symfony2 core features do not and will never rely on any ORM.

I don't like MVC because that's not how the web works. Symfony2 is an HTTP framework; it is a Request/Response framework. That's the big deal. The fundamental principles of Symfony2 are centered around the HTTP specification.

I don't like MVC because the web has evolved a lot in the recent years and some projects are much different than projects we had some years ago. Sometimes, you just need a way to create a REST API. Sometimes, the logic is mostly in the browser and the server is just used to serve data (think backbone.js for instance). And for these projects, you don't need an MVC framework. You need something that handles a Request and returns a Response. You need a framework that implements the HTTP specification. HTTP streaming is yet another example that does not fit well with the MVC pattern.
Why does it matter?
We need to better advertise Symfony2 as a set of reusable components because I strongly believe that the community growth in the coming years will mainly come from the adoption of the components.

And Symfony2 adoption is all about how we sell the project. But it's also about the perception of the project people have. And as symfony 1.0 was mostly a monolithic framework, a lot of people still think that Symfony is indeed a monolithic framework. Hopefully, with the release of Symfony2, the perception is a bit different now, but it will definitely take a lot of time to change people minds.

It matters because even if new frameworks are created every single day, I think that in the "enterprise", there is room for only 2 or maybe 3 PHP frameworks. The question is: how will we win the framework ~~war~~ competition?

First, we need to lead the pack technically by constantly innovating. Getting inspiration from other technologies, other frameworks, and other web languages and adapting some of their concepts to PHP is a key factor here. Acknowledging that the web evolves is also very important. And Symfony2 is probably a great step forward in this direction with many great innovations like bundles, HTTP caching, distributions, dependency injection, templating engines, annotation configuration, asset management, the stable API, the web profiler, and a bunch more.

We will win the framework ~~war~~ competition if Symfony2 is everywhere. And a full-stack framework will never become a standard in the PHP world. So, we need to find another way.

Being everywhere is about sharing. First, by not reinventing the wheel ourselves and by inte
Truncated by Planet PHP, read more at the original (another 33381 bytes)

My RSS » Items by Fabien Potencier

Feeds

Items by Fabien Potencier

Posted: January 24th, 2012, 11:39pm MST by Fabien Potencier

Posted: January 23rd, 2012, 5:51am MST by Fabien Potencier

Posted: January 21st, 2012, 12:43am MST by Fabien Potencier

Posted: January 19th, 2012, 5:09am MST by Fabien Potencier

Posted: January 17th, 2012, 2:39am MST by Fabien Potencier

Posted: January 15th, 2012, 2:53am MST by Fabien Potencier

Posted: January 13th, 2012, 3:14am MST by Fabien Potencier

Posted: January 11th, 2012, 7:02am MST by Fabien Potencier

Posted: January 9th, 2012, 1:27am MST by Fabien Potencier

Posted: January 7th, 2012, 10:41am MST by Fabien Potencier

Posted: January 5th, 2012, 3:57am MST by Fabien Potencier

Posted: January 3rd, 2012, 3:03pm MST by Fabien Potencier

Posted: October 25th, 2011, 1:48am MDT by Fabien Potencier